Can Passkeys Replace Passwords?

Today, I am taking an initial look at the FIDO Alliance replacement for passwords called passkeys or you may hear it called FIDO2. FIDO2 is the specification name. Google has recently announced their full roll out for passkeys a few weeks ago. Apple has support for passkeys in IOS16 and macOS Ventura, but won't have full support until this fall (of 2023). Microsoft said they will have full support for Windows by the end of the year (I do not know if this will just be Windows 11, or if it will include Windows 10 as well).

The artwork: I generated this "photo" using AI. This Week it is the Greek Guardian Atalanta, she was a huntress and a warrior. Having been born a female her father left her in the woods as an infant to die, she was adopted by a bear and raised to adulthood as a hunter. During the voyage of the Argonauts, she invoked the protection of Artemis to protect the ship and crew, and fought alongside the men in the battle of Colchis.

Chapters
00:00 - Start
00:10 - Can Passkeys Replace Passwords?
00:23 - Why do we need to replace passwords?
05:38 - Relying Party
06:16 - Registration
07:54 - Login
08:58 - API
09:36 - Roaming Authentication
10:42 - Sync vs Hardware Bound
12:44 - Synced or Hardware Bound which one to use?
15:35 - Transitioning to Passkeys
16:36 - Roaming
17:29 - Just a few more things...
19:24 - Synced Scenatio
20:18 - Enterprise and Shared Passkeys
23:37 - Final Thoughts
25:40 - Outro

Follow me:
Twitter @djware55

#Passkey #FIDO2 #Passwordless

[edhahaz]

This goes over my head... have to come back to this premise sounds interesting

[capability-snob]

I'm always impressed by how far these companies will go to avoid doing object-capability security. Experts solved most of the problems raised here decades ago, and the resulting systems tend to be easier for users to reason about. The most common example is revocable delegation, using either the membrane pattern or a cryptographic equivalent, but there is also auditing using the horton protocol. More fundamentally, having each credential refer to a single resource makes it easier to confine delegatees to a subset of your authority.
Unfortunately for the companies promoting authkeys, capabilities make it harder to track users. It's much better for them if you must log in to do anything, so they have a user account to tie things to. So if we want usable security, we probably need to avoid looking to big tech for the solution.

[alexxx]

Still waiting for a 2FA smartphone access: bio + pin. Somehow it's either bio or pin/password.

[YouIos]

Thanks for the informative Video!
Really interested in using passkey instead of passwords off of my password manager.

Sorry if this is a dumb question but can I not register a second device on the same account in case I lose my primary one (e.g. a YubiKey)?

[CyborgZeta]

As a dedicated Firefox user, and also a user of Firefox's password manager, it will be a while before I could make the switch to passkeys. Assuming they become the new standard, of course.

[gotoastal]

There seems a lot of issues. Currently most services that support U2F token, still allow TOTP as a fallback which is useful for recovery, but this won’t. I tried cloning an OnlyKey naïvely assuming the U2F would clone too, but it doesn’t so to register a new service, I need to register both keys which is so inconvenient since ideally the backup would be in a safe or lockbox—but allowing those to be duplicated has issues too as in theory an attacker could clone it and still leave the original behind. The idea that you need a new key for every site is problematic too as OnlyKey can support 16 keys/slots, but most keys have just one and most of us have at least 16 services anyhow. Seeing how often-used phones are, they're not uncommon to break, not just get lost which could make key recovery difficult. I'm afraid of banks moving to this too because Linux still isn't supported, and I doubt feature phones ever will, and hardware tokens aren't the cheapest which really hurts accessibility. I could imagine the bank giving you a key with your account and now your physical keychain mimics as janitor's with every service you submit to.

[captainandre]

Great video thank you. Investing 101: n’t put all your eggs in same baskets. Internet security 101: don’t put all your eggs in same basket. IMO bad idea with my master key stored in Apple ICloud. If someone gets a hold of my biometric or master key in the cloud then they would access ALL my accounts.

[Gosu]

I wonder about this part on how enterprise would audit this or revoke access. I'll probably need to watch this again to understand those points, but wouldn't passkey simply be associated to an identity you have at a company and from that standpoint nothing would change (even if tooling would also be updated to work with this)? Company doesn't change/remove my password when I leave — they simply remove my identity/move it to different OU with less access. Doesn't this support access control?

[Sigulete]

Such a good explanation. Now I know passkey is not for my use case.

[alexxx]

How the problem with shared accounts is the passkeys problem, because we had the exact same problem with password protected accounts? Shared accounts is bad security practice. The only hard solution to that is making passkeys unsharable, and probably unrecoverable, stored securely in hardware key stores.

[DougForce]

Well, I was pretty sure I didn’t fully understand passkeys before watching your video. Now I’m convinced that I don’t understand passkeys…. Lol

[stevek]

Ok, regarding loss of device, or changing devices, say Android to iPhone is authentication and recovery easier and more secure via yubi key vs the phone? I switch platforms every other year. If yes, I assume to not lose Yubi key. So, can I have a second Yubi -clone?- in a locked safe in case yubi 1 is lost, will Yubi 2 be as equally usable as Yubi 1 was?

[anasouardini]

I don't think we need websites/apps and browsers to support PassKeys, password managers + little scripting save the day.

[catsupchutney]

Too early in the morning to follow how this works.

[mnoxman]

90 accounts. How quaint! 3x that number if your a industry specialist.

[Ancipital_]

If services allow me to add multiple keys so I can share accounts with my spouse I'm totally ok with it, but only as an extra step, so password + passkey.

[craigpeacock]

This is a really bad idea. This can easily be used to disable our access to services we wish to use. Until there is me reinforcement against governments against abuse, I do NOT recommend.

[mnoxman]

When google forced people to use "app passwords" they did a few things to make them weaker so they could 'crow' about it later. The wen't from (at least) 20 to 16 characters in length and took the key space from the full keyboard + UTF-8 to less than full keyboard thus making it easier to 'brute force' a password. TOTP is great for 'set and forget' cookie/Kerberos sessions but sucks for computer-to-computer.

Passwords minimally fall in to these categories. That which is close to you (phone, desktop, tablet, etc). Those are the ones that you need to keep in your head. Passwords that are 'background' or computer to computer passwords. (E.g. wget/curl fetching with a user ID and Password. Apps like Thunderbird/Procmail.) Passwords that managed a Cookie/ticket (e.g. Google, ebay, amazon, etc). TOTP passwords are great for the last category.

What would be good is if both TOTP and LONG STRONG were supported (and this includes enterprise authentication. Talking to you Hitachi). Allow a 1024 BYTE password with all UTF-8 characters allowed [yes including spaces] is the best choice for this last group since those passwords are generally managed by a password manager like Keepass, password safe or others. Allowing UTF-8 characters means a much bigger keyspace to search for the same size password.

A 5-8 dice words mangled by UTF-8 characters would be pretty strong. Not as strong as a TOTP but would allow for automation and for strength. Yet all I see is places like Google falling back to polices and technology of 25 years ago and blaming a user for a breech.