Passkeys are not passwords https://notes.neatnik.net/2024/08/passkeys-are-not-passwords

@adam I wish more services would allow using passkey only, it’s great to be able to log in quickly with passkey but password part is still vulnerable.

@adam Hmmm in that case I don't think I understand passkeys. Time to find out.

@amit I didn’t mention it in the blog post, but passkeys are built on the existing WebAuthn standard (the same one used by hardware keys, like Yubico) and that’s the standard requiring private keys be tied to the device or tool that generated them (and be unexportable).

Also, lets say some password wallet decides to be nice and allow you access to the passkeys(for backup/transfer), a service provider knows the app you are using and can block it. (3/3)

@adam I want to love passkeys and go all in but… (1/3)

Not being able to access passkeys seems like a big issue. How do you back them up or migrate them to another service? If the answer is, you don’t, you have to regenerate them…. besides being a PITA if you have a lot of logins, it means that every service that uses passkeys will also have to implement alternative means to login. This negates some of the security passkeys give you. (2/3)

@mcg Passkeys are built on the same WebAuthn standard that hardware keys (like Yubico) are built on, and they’re intended to work the same way. If you lose your Yubico, you have to visit every site where you set it up and remove/replace it, same as with a passkey. Sure, that sucks, but that’s the security tradeoff you get with something with a private key that can’t ever be included in a breach and that is unphishable by design.

@mcg Re: alternative login means, 99% of the things I use have email + code or “magic link” as a fallback, and yeah, that poses its own set of security challenges. For most of us, our online security is only as solid as our email security. But that was a problem before passkeys existed, and will continue to be.

@mcg I actually wouldn’t blame anyone for blocking passkeys originating from an insecure or out-of-spec implementation. The whole point of passkeys is to raise the bar on security, and that only works if the phish-proof aspect is preserved (as per the WebAuthn spec). If passkeys can be exported, they can be phished. It’s totally understandable that a large website with lots of active phishing campaigns might want to take action to prevent their users from being insecure.

@adam How do passkeys make things more secure, if any site that uses them also has to implement an alternative login or recovery?

@adam And let’s pretend passkeys are everywhere, your email account uses it. You’ve lost your passkeys because iCloud burped. How do you recover?

@mcg I think the point is that they’re more secure than passwords (because they’re not stored anywhere other than on-device or encrypted in a compliant password manager). They’re an alternative to passwords, they’re not a panacea for all website security.

Sites already offer email-based backup logins and account recovery because people forget their passwords, and they’ll have to continue to offer ways for people who lose their passkeys to gain access.

@mcg Despite that, we’re still better off with passkeys than passwords. I’d rather use services that offer passkey + email fallback than password + email fallback. Whether email fallback is good or safe is a totally separate issue (that’s also worthy of discussion), though.

@mcg Ideally you’d have multiple passkeys on your services, the same way that if you use hardware keys you’re encouraged to have multiple physical keys (in case you lose one). If something goes wrong with one source of your keys, you have a second (or third) to fall back on.

But yeah, not everyone will do that. So if they’re unable to access their passkey for some reason (e.g. locked out of iCloud), they’d just have to use the usual email fallback for whatever service they’re trying to visit.

@mcg Oh, lol, sorry, you said *email account*. Every email account provider has a recovery procedure, so you’d have to follow that. And yeah, it’s a huge pain. But that’s where having multiple passkeys can come in handy.

@adam Passkeys make the easy/normal path for normies easier, but the failure path for everyone, much much worse.

@mcg In all fairness, the question is equally valid if you swap passkeys with passwords: what do you do if you’ve forgotten your password (or can’t access it because you’re locked out of your password manager) and you can’t log into your email account? It’s the exact same situation—you go through account recovery. Passkeys aren’t changing that dynamic at all, nor were they ever intending to.

@adam Almost all password managers allow you to backup/export items other than passkeys.

@mcg Right, that’s them following the WebAuthn/FIDO standard. It’s the same reason you can’t export your Yubico’s private key—it would defy the security strategy entirely.

I know it runs counter to everything that we’re used to, but it really is an objective improvement in security. It just feels weird because we can’t treat passkeys the same way that we treat other kinds of data.

@mcg I just don’t really see it. The failure path for a lost password and a lost passkey are identical. The remediation at the end is slightly different: setting a new password vs. adding a new passkey. For some reason we think the latter is more of a pain than the former, but with most implementations you’re just one fingerprint or FaceID away from adding a new passkey to any site.

@adam Oh cool, so my big issue is apparently going to be fixed soon https://infosec.exchange/@iamkale/112831314369678941

@adam Hmmm, makes sense and I understand why they must be different from passwords. But I still need to figure out how they work, especially integrated with password managers. I struggled recently logging into omg.lol on a new machine because I had enabled passkey a while back. Or so I recall.

@amit Yeah, the omg.lol setup currently uses passkeys or sends a login link via email. So switching machines can definitely be an inconvenience where passkeys are concerned.

I’m nearly finished with a new login system that will still support passkeys, but more importantly it will support everyone using the authentication method (or combination of methods) that they wish. No more forced approaches from me! 😄

@adam I ran across this via @simon linking it.

Does that mean that 1password-based passkeys are antithetical to what they're supposed to be. Or is it enough if it's impossible to export and reimport the passkey from 1password?

@zellyn @simon Yeah, you can’t export passkeys from 1Password in any way that they can be accessed or used by anything other than 1Password — so that’s fine and fully compliant with the spec. There’s an effort underway that will establish a standard for passkey export/import between password managers while still preserving the safety of the private key (meaning the key wouldn’t be useful to anyone if uploaded somewhere else, preserving critical the anti-phishing element of the setup).