Users understand passwords. They even understand entering a 6-digit number that was texted to their phone. That's about it. It has to be that easy, or it will fail. If you have to start talking about public key cryptography, you're doomed.
Previous attempts at replacing passwords were all nonsense. They were all about replacing symmetric keys with asymmetric keys, which to anyone who doesn’t understand the difference, it makes no sense. I mean even if you understand the difference it hardly makes any difference in usability. I still have to manage my private key and secure it myself. the only usability difference is that I don’t have to transmit it, which is not even something that I do, it’s something that whatever software I’m using does.
With a hardware key, it makes intuitive sense. Sure, maybe the distinction between a TPM, Secure Enclave, Knox, Titan or a YubiKey is hard for non-technical people to understand or reason about, but luckily for WebAuthn simple external hardware keys are becoming a norm. I have seen many completely non-tech companies adopt YubiKeys which I was delighted to see .
Hardware keys are all about asymmetric cryptography, and are just basically another way to store keys. You still have to manage those keys. It's just way harder, because now it's a physical thing that's much harder to backup/copy by design.
Do we? My password manager has 1031 entries. I know maybe 3 of my passwords. For the rest, the fact that it's technically a password is mostly irrelevant to me. And there are a number of things I use that are magic link logins, where the "password" is a one-time key that gets emailed to me and used immediately.
So from my perspective, the notion of "password" is wildly obsolete; most of what passes for that these days is machine-generated strings that don't know and almost never see. I'd be perfectly happy to go one step further and have a proper protocol such that BitWarden and the site talk directly, leaving me out of things.
Another way things like linking a TV to an account happens is not with a fixed string that we in theory invent and memorize, but with a dynamically generated one-time code. For me that's obviously better than a password, in that the code will be shorter and time-limited, while the time window to misuse a password is infinite.
I want to share passwords of some sites and not share for all sites. If I share a password, I don't want to bugged whenever they try to log in.
Most sites also support some kind of fallback method, like magic link or a password.
some of them do, but a large portion of users do not understand why they need a password, do not understand how it keeps their account secure, or do not remember any password beyond a single use. there's a high proportion of people who do a "reset my password" every single time they log in to a service, and a smaller but still significant portion who are simply unable to sign in to any service that requires a password. they need a "computer-savvy" tech person to help them, or they just don't use it. the password is not some paragon of excellent UX that we're struggling to replicate.
Users see passwords as a barrier they need to defeat to access the thing they want, and will use any means available to them to defeat that barrier, security be damned. passwords are terrible.
Exactly right. My mum has an iPad, secured by a PIN. This in itself is already an annoyance, but fine. Next, several services on the device have their own authentication. Say, the Apple ID. Email. Spotify.
The thing tech people fail to understand is that many people, including my mum, are not able to conceptualize these services, they lack in tech skills but also in abstract thinking in general.
She sees the device as a single physical device. She owns it and it should stop bothering her about access. She has it in her hands, what access?
I worry much more about the account recovery UX and issues. If you lose your phone, how to replace it? Is that replacement path a prime target for attackers? I’d argue key distribution (issuing, rotating, revoking, multi-device) is where almost all the subtle pitfalls are.
Passkeys have a lot of questions in that regard. A password is simple: "keep this secret and only give it to the person it's for". You can read it, you can write it down, the rules of how it is distributed are obvious if not secure.
Passkeys on the other hand are already not being explained: "keep this secret. Then, your device will magically use it somewhere else. But actually we keep it in the secure element, Also sometimes you can't move it to other devices. Also sometimes the part we send won't work if we send it to the wrong person, or if it's intercepted..."
Of these, the part I really worry about is the synchronization one: everything about passkeys is being structured for corporate lock in. Because the ability to manage them like passwords is not front and center, it's being treated as an after thought. "We'll handle synchronization eventually or "oh, well it'll be on your other iCloud-connected devices..."
If I want to take an offline backup? If I want to write something down or print something out to cram that passkey onto another device, can I? Or is there an additional factor there which is empowering the service to decide if I'm allowed to do that?
Too strong of a statement imo. The password happy path is still a lot of friction every time you sign in, which is why everyone except banks sets their refresh cookie expiry to months or years. Not great, cookies don’t even live in the secure element. But if you torture people with typing passwords every day they won’t come back unless they have to.
> A password is simple: "keep this secret and only give it to the person it's for".
You’re missing the recovery path. That’s not obvious at all - usually a password reset through a side channel like email. In those cases, the email is your de-facto identity, and the password is like a refresh token that is stored in your brain.
Now, I’m not saying this is better with passkeys, just that there is more to password auth than meets the eye.
> Of these, the part I really worry about is the synchronization one: everything about passkeys is being structured for corporate lock in.
Me too. I think it depends a lot on the interop story. In the best future, we get something like a password manager standard, which interops with browsers and apps. Current password managers are well positioned to use passwordless auth. As a user, I could then use say Bitwarden on all my devices, and use passwordless as it comes available to more services.
But a lot of questions are still unresolved: what if I need to sign in from a public computer? Will account recovery still use email as last resort?
Do they though? Sure they can use them, but that's a far cry from understanding.
We can keep telling people to use long passwords, to use different passwords for different webpages, to stop storing them in unencrypted on their phone or desktop.
So far this has had limited success and even with a better than average understanding users usually just end complain they can't remember all that.
At which point you try to teach them how to use password vaults. Which increases the layers of indirection by 1. Which is never a good thing when you need to explain stuff.
And then you've got webauthn, which in theory solves quite a few of these problems by simply giving people two buttons 'Give me an account' and 'Log in using my account'. Unfortunately it does this by increasing the levels of indirection another time by effectively being built on top of a password vault (but not the normal kind of password vaults because that would be too easy).
If users understood passwords they would know how and why to use a password vault. If they understood password vaults they'd understand how webauthn could help eliminate passwords.
What is a passkey? Most material I've read just defines them as a "credential" that is "used as an authentication method." That's it. It's a credential. What kind? Who knows. Only when you arrive at the Apple developer page you finally learn that they are "cryptographic key pairs". And then you start digging into WebAuthn, get a throbbing headache, close your laptop, and do something else productive instead.
The bigger issue is that you are currently locked to a device (or, in some cases to a set of devices). This makes it tedious, because:
* you have to have an account recovery mechanism beyond the scope of WebAuthn
* you have to add each device you want to login with
We'll see if these issues get resolved, but I think that the working group is, well, working on it.
What if my phone dies with all my keys?
Do I need to maintain backups on 3 devices? I assume manually to be secure. This is so much time, esp for throwaway nonsense accounts I use yearly.
What if my phone died during a trip and backups are at home in another country. How do I email someone now?
My mom forgets a password each time she has to retype it. What if she breaks her phone with all the keys and no backups.
How do I log in on a computer without usb access that is not connected to the same network as my phone with the keys? - this workflow is already broken with gmail 2FA process with approving in gmail/youtube app.
If I even reset a passkey, how to use a friends device if mine is broken currently?
This is all solved with a password reset email.
Platform authenticators are built around the synchronization concept so it’s easy to keep multiple devices active. Unfortunately, Apple, Google, and Microsoft have committed to but not yet enabled cross-platform sync so until later this year you’d need to register both, say, your iCloud Keychain and Google Chrome keys separately.
Because each one is implemented separately you’d need to check your synchronization service of choice but note that e.g. iCloud explicitly supports recovery when you’ve lost all of your devices permanently:
https://support.apple.com/en-us/HT213305
> How do I log in on a computer without usb access that is not connected to the same network as my phone with the keys? - this workflow is already broken with gmail 2FA process with approving in gmail/youtube app.
Your computer doesn’t need to be on the same network (it uses Bluetooth). This is also a contrived situation: if you work on a computer which has been locked down that much, you don’t want to use personal accounts there anyway.
There is a solution to that, however, along with every other one of these edge cases: you type in one of the one-time recovery code the service made you setup up when enrolling. Unlike the password reset email, that isn’t commonly exploited by attackers, too.
An "Insert the dongle" popup is instantly understandable, and we never had any problem with employees learning how to use them. Windows, Linux, Macs all eat GIDS smartcards without an issue, no extra drivers needed. Works across well web access, ssh, SASL, kerberos.
And now those people want us to move to FIDO keys, which come with each new version, one more problem, and don't work with anything, but Google stack.
You can even setup your office access control on the same smartcards.