Passwords suck. Can passkeys replace them?
18 points by darccio
18 points by darccio
Until such time as we can troubleshoot what's gone wrong, there is zero point in trying to use passkeys. I haven't looked in a year or two, but last time we tried, the only thing we could do when passkeys go wrong was delete the passkeys and hope it works the next time around. It's technology, it's guaranteed to go wrong sometimes. Near as I can tell the only companies that offer passkeys are the companies with effectively zero end-user support. I can only assume it's for the same reason as us, if it breaks, there is nothing you can do to fix it.
I remember trying to log into some website with a passkey and it failed in a completely opaque way. Logging into it using the same passkey (stored in my password manager) on a different browser worked. That's a failure mode that's clearly impossible with passwords.
I set up passkeys on my personal AWS account and added them to 1Password because… that's what you're supposed to do, right? I even confirmed it was working by logging out and in again.
Some time later, my server went down. When I tried to log into AWS, I discovered my passkey had magically stopped working. (And inconveniently, automated reset emails were also broken.)
I'm not sure what happened. Maybe AWS changed the login page and 1Password couldn't recognize where to put the passkey? I tried different browsers and different passkeys for different sites, and AWS was the only place I was locked out. I don't know, because there's no fixing the actual cause—there's only contacting customer support to let you in, and never using passkeys again for AWS or anything of similar importance.
automated reset emails were also broken.
If you were using a password and forgotten it at that time, would you then conclude that it's best to never use passwords again?
Yes, actually! That's why I use a password manager wherever I can.
I've forgotten passwords I thought I'd memorized. Passkeys have mysteriously stopped working. But "random strings in 1Password (and sometimes TOTP)" has not yet failed me.
Agreed. Passkeys as implemented by all OS's and browsers are VERY opaque. I mean you definitely want some opaqueness, but there needs to be more ways to troubleshoot this stuff for our users before we can ever roll out passkeys.
For us as an organization to implement it to our users, it's looking like We Are Never Ever Getting Back Together.
I wonder if there's a way to make them more tangible?
TOTPs are sometimes annoying, but at least the annoyance makes it clear what's happening: there's a number in this thing, and it has to be typed or copied into that thing. I can see the moving parts! It's pretty much my ideal auth workflow, and I only wish it was phishing resistant.
Exactly, we love TOTP and Yubikeys, we support both. With TOTP's it's usually a clock drift problem. At TOTP setup time, we have the user type in a code and we calc the clock drift and help the user if it's > 60 seconds.
You can buy hardware TOTP devices, those things work for a couple years, and then you have to replace them because the clocks get stupid. We don't like them. We much prefer Yubikeys HOTP or their proprietary stuff which is basically HOTP. All of it is debuggable.
I prefer easily debuggable tech, but in practice use a lot of useful tech that I can't practically debug.
That said, the alternative to passkeys isn't just passwords. It's password+SMS or password+TOTP.
SMS not delivering? I try another number, or give up.
TOTP code not working? Client/server clock drift? Client/server disagree on the secret? On the times it hasn't worked for me, I retry, or give up.
Sure, but in the case of TOTP(which we support) and Yubikeys(which we also support), we can debug them. They are just text input fields in our login flow. You can debug a text input field.
We had to write our own TOTP implementation, and we can tell when they sign up for TOTP if they have clock drift. I forget how many TOTP calcs we do, I think we go out a week or something, either direction. Anyways, during signup we make you type in your newly setup TOTP code, and we calculate the clock drift. If it's larger than 60 seconds we tell you how to fix your system clock.
It's not rocket science, and you can give tech support things to check. We've had TOTP and Yubikey support in for a long time now with basically no troubles. A decade or more? I dunno. I'm too lazy to look it up.
OS and browser vendors make passkeys unsupportable, because it's so opaque. They seem fine with that. We are not fine with that.
I'm using passkeys on various sites throughout the internet and they seem to work perfectly every time, so perhaps they are not as unsupportable as you think.
I'm glad you are having a good experience! There are definitely users on the happy path out there with passkeys. You seem to be one of them. That's great! We had several when we were trialing support for it.
Have you ever had to support passkeys to users? Have you ever tried to troubleshoot passkey issues for anyone? I have, with roughly zero success. Every time passkeys come up, or people ask me about passkeys I always bring up that passkeys are great in theory, but nobody has proven they can support them yet. I've never met anyone that can support passkeys when they go wrong. I'd love to hear from anyone that has ever done it successfully. I tried and failed.
I'd love for passkeys to be supportable, if someone could show me how to support passkeys to users, I'd start implementing passkeys again the next day. Until then I'll just wait patiently and try again in a decade or so. By then passkeys will either be a totally solved problem or effectively dead. Based on my past experience, I'm currently betting on dead. I'd prefer to be wrong.
That's fair. Exactly whether to bother implementing passkeys will be site-specific.
Factors where it might make more sense:
We are most of your list, which is why we were excited about Passkeys. After passkeys failed, we looked long and hard at what the DOD managed with their pubkey auth. They are the only ones that have managed it over HTTP that I'm aware of. Sadly doing what they did would be a giant amount of work and expensive. Not to mention not nearly as seamless UX wise. We haven't gotten that desperate yet.
How do you troubleshoot a password going wrong?
When passwords go wrong, it's usually your own fault (a refreshing thing!). If you mistyped it on a touchscreen, you can try again one character at a time, watching the letters that pop up. If you forgot if the first letter is capitalized, you can try both variants. And so on. There's stuff to troubleshoot because the problem is on your end.
It's very, very rarely the case that the server forgets your password and just your password.
It’s never happened to me; but if a server had forgotten my passkey, I’d (also?) be extremely leery of both that vendor and the new technology.
To be fair, I'm not sure exactly why my AWS passkey stopped working. It's probably not that AWS "forgot" my passkey, like the row fell out of their database or something. But somehow my account and my passkey lost an invisible link that held them together.
First, how do you know it's actually the password going wrong?
What if it's a typo on their username or using the wrong MFA token or using the wrong URL, etc. There are tons of failure modes unrelated to it being an actual password problem. But if we determine it really is a password problem, then our helpdesk staff can help them reset their password.
One example around passkeys: With the whole phone has to be near your computer thing, if your passkey is on your phone situation, there are tons and tons of failure modes unrelated to the actual passkey being wrong. How do you troubleshoot these issues? Last I looked you really can't. I mean you can make sure the phone is physically close to the computer and the BT radios are on, but past that you can't really troubleshoot that, given the tools we had at the time.
Maybe it's better to troubleshoot now, but I'm betting it's not.
I guess since I gave up typing passwords and went all in on password managers years ago, I had forgotten these pains.
What are the failure modes with the actual passkey being wrong though? My favourite part about them is that there’s never a doubt about which passkey goes to which site. Heck, some sites don’t even make you enter a username beforehand— open the site, click login, tap the passkey, done!
Auth in general is just a PITA when you have to support it, doesn't matter what system it is. We certainly try hard to encourage password managers, we even provide one to internal users. Not everyone has drunk the kool-aid yet.
What are the failure modes with the actual passkey being wrong though?
That's my whole point. There is NO visibility into what's going wrong with passkeys. When passkeys don't work nobody knows what to do. If you delete and re-setup the passkey and it still doesn't work, then what?
The OS and browser vendors make troubleshooting passkey issues basically impossible. When annoying the OS vendors and browsers, they just shrug and say we don't know why either.
We might try again in a decade or so, assuming passkeys still exist. So far the only people that has ever had widescale adoption of HTTP based pubkey auth is the DOD. Maybe passkeys will get there, but last time we tried, it certainly wasn't looking likely.
With the whole phone has to be near your computer thing
May I ask what thing this is, because I've never heard of it.
It lets you use a passkey saved on your phone to sign in on another device.
Android and iOS both "support" it. I mean they say it works and it does sometimes work... But if you have problems and annoy them about it, they usually can't make it work either. At least that was our experience a year or two ago.
Sure, that's supported, but imho it shouldn't be the usual auth mechanism. If a device doesn't have a passkey, the user should probably log in with email and then just set up a new passkey.
The way an ordinary non-technical person “troubleshoots” a password issue is to do a reset/recovery.
Troubleshooting a passkey issue ought to work the same way.
This whole thread is like missing the entire forest here. When your user calls you and says "I can't login". Them forgetting their password, or the passkey being actually lost or something is just one of 100k different possibilities.
I know all the tech companies have basically adopted the Google tech support mantra, but some of us still actually have to care about users.
A year or two ago, we implemented passkeys for our auth system and started a pilot rollout. Our tech staff couldn't reliably figure out how to make their own passkeys work. We annoyed OS and browser vendors, they couldn't figure it out either. We turned on all the debug we could(which was basically nothing).
When it might take a week or more of high-quality debug time to get a single user to work(and then not even reliably sometimes), we just pulled the plug and deleted all of that code.
Were we holding it wrong? Maybe. Even today I don't know of a single org that actually has end user support that has turned on passkeys. Maybe there is one? I'd love to talk to whoever has to support passkeys there.
I've never heard about any human ever that actually supports passkeys existing in the world. I'd love to meet one someday. I (and my team at the time) tried and failed.
the only companies that offer passkeys are the companies with effectively zero end-user support
This is the core problem and them pushing passkeys this hard is extremely shady.
No, not until users can control their key material, export it for safekeeping and re-import it elsewhere when setting up new devices.
KeePassXC tried to give users this control a couple of years ago, and were threatened for it:
To be very honest here, you risk having KeePassXC blocked by relying parties
Ah, I hadn't seen this. So they want to actively prohibit people from being able to export their passkeys in a file format that a human could make sense of?
So the idea is, that a HSM is only secure if the private key cannot be extracted. Which is why the guidance with passkeys is not that you should be able to back them up, but that you should be able to add several. I have multiple yubikeys that is use with WebAuthn/Passkeys and for most (or at least important) services I register more than one.
The average user is not going to bother. And that's fine, if there's a reasonable way to recover the account. But the recovery procedure needs to be as secure as the primary login procedure, otherwise it's just a lower fence in the backyard. And this is why Google, Apple and Microsoft have also implemented cloud sync for their passkeys. Which I'm not terribly happy about, but understand that it's done for average users. Getting all the other advantages of passkeys is worth it. I don't use a cloud synced passkeys store, I use yubikeys.
One of my favorite use case of WebAuthn is that you can connect to your online accounts on any insecure computer [...] by simply scanning a QR code or plugging a hardware security key without risking the leak of your credentials (don't forget to logout).
I don't think I'd want to plug in a hardware security key into an untrusted computer - 99% of the security keys I've seen don't have physical screens to confirm what you're accepting, so for all I know I might be letting someone ssh into my server or take over my email account. That has always made them seem kinda pointless to me. Scanning a QR code does make sense (that would let me verify what I'm authorizing, right?).
Obviously this wouldn't do anything against more sophisticated targetted malware, which could fake the logout, or just automatically do all its evil deeds right after you log in. Still, in practice people do log into their accounts on untrusted machines, so that's pretty useful.
You can't be pro-password managers and be anti-passkeys. Passkeys are just the natural evolution of password managers with strong cryptography and phishing resistance built-in.
Now that's hyperbole, because I absolutely can. My password manager already has "strong cryptography", authenticating myself with a pre-shared key that's unique for each site is perfectly solid. I might also be willing to sacrifice phishing resistance for the simplicity of a "traditional" password manager, which could reasonably be implemented in around 2kloc and "finished" - maybe if supply chain attacks are more of a concern for me?
authenticating myself with a pre-shared key that's unique for each site
Are you talking about HOTP? Because a password is no way shape or form a pre-shared key.
You're right, I was too loose with terminology. I intended to compare them to API tokens - where most people would agree that just authenticating yourself with a token known by both parties is sound... but I suppose that's not a fair comparison.
no they can't until i'll be able to save them passkeys on my tape backup and restore them later on a brand new device with a different OS. not transfer, but RESTORE.
we do have asymmetric cryptography, which works perfectly as demonstrated by ssh. public/private keys of course pass the test above.
maybe i'm wrong, but passkeys appear to make someone else or a device your gate keeper.
with passwords, ProviderA can block your account with ProviderA, but there's no PassKeyProvider who can block your access to ProviderA, ProviderB and so on. how can we be so naïve?
save them passkeys on my tape backup and restore them later on a brand new device with a different OS
What makes you think that you can't do this? s/tape backup/USB drive/ and I have done this multiple times.
Maybe phrased another way: with passwords, no one can stop you from doing it. With passkeys they can, e.g. via attestation.
Effectively they can't, because Apple devices don't do attestation. So basically no one can enforce it for fear of locking out a significant part of their user base.
there's no PassKeyProvider who can block your access to ProviderA, ProviderB and so on.
The 'passkey provider' is your device, your hardware. If you don't trust your hardware then you wouldn't use it at all.
i only trust god and backups, not a device which locks information i own from me. yet i still use it for mandatory purposes like online banking, public transportation and delivery boxes.
The article claims:
You are absolutely not forced to use the passkey managers offered by Big Tech and can use 3rd-party ones
I would like to see evidence of that. My biggest objection to passkeys is that I can't control them. With a password, I can look it up on my phone, type it into my locked-down corporate laptop, and log in. I can store a backup copy of the password in case my main one is compromised. I can guarantee that even if Google/Apple/big-tech decides I am not welcome , I won't lose my password. I can allow my wife to use my password to log into our health insurance website which won't allow her in because although she is covered by it she isn't the employee of the company that pays for it (US health system sucks).
All of these seem to be a problem for passkeys. If they aren't, I would like to hear about it.
The entire point of passkeys is that you can't look at thenm or backup them, they never leave your device.
And yet there are multiple major passkey deployments that do just that! Apple shares them across multiple devices via iCloud; I suspect Google does similar. 1Password has its own sync backend. Bitwarden does too. And KeePassXC lets you roll your own.
That's certainly A perspective. There are two opposing world-views: The ones that want to treat the passkey as "special" and move it around everywhere, and those that want to treat them as disposable.
Both have valid use-cases and in theory webauthn's spec supports both use cases, but OS and browser vendors definitely don't all support both use cases equally well.
Personally, I put my passkeys in 1Password and it syncs and moves my passkey around wherever I go. When passkeys work, 1P makes it seamless and easy to use, regardless of device. Sadly only some vendors like 1P are part of the cool kids club that can do this semi-reliably. My understanding is most open source implementations were told they were definitely not part of the cool kids club, and can't do things like this.
Your understanding is incorrect, sadly whoever gave you this understanding spread FUD. Open source implementations definitely work with passkeys, eg https://github.com/search?q=repo%3Abitwarden%2Fclients%20passkey&type=code
Apparently I'm just out of date. It's been a while since I cared much about passkeys. I apologize. KeypassXC was threatened here: https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200
Though apparently they worked it out as it seems KeyPassXC supports passkeys now? I think Bitwarden is the only other open source one that does passkeys? None of the others I quickly checked did.
You don't control it. Attestation means that vendors can decide that they want the passkey to only come from e.g. an untainted android/iPhone (they already do that in regards to rooting). And on those devices, you don't control passkeys (or it can be made so that you can't). Then the only way to restore a key is to have an account with Google/Apple. Which btw also means that they can login everywhere you can. Great.
vendors can decide that they want the passkey to only come from e.g. an untainted android/iPhone
That's impossible because, as I've said many times, Apple doesn't do attestation for consumer-level devices. And they effectively can't decide to enable it in the future because that would mean killing all the passkeys they've already generated so far and making a lot of users very unhappy.
Apple doing the right thing here is good for now but attestation should have never been part of the spec.
For all the talk about attestation, I’ve yet to encounter a vendor that uses it. (I have 100+ passkeys that aren’t bound to big tech hardware.)
@mcherm correct me if I'm wrong, but were you referring to Google/Apple as in, iPhone encourages me to store my passkeys in Cloud Keychain? And if I run afoul of Apple, my passkeys are at their mercy?
In that case, the concern really is about losing access to multiple places. Every website has a unique passkey, sure, but corporations are incentivized to encourage you to put them all in their basket.
I put my passkeys on FIDO2 security keys. I don't use the Apple/Google providers. Some use keepassxc, which stores them on local disk.
Using multiple passkeys relies on the site supporting multiple passkeys per account, which is the norm, but not universal. (All sites I use allows this, which I do recall seeing a site that only supported one passkey per account.)
But this isn't unique to passkeys.
I have a joint groceries account with my partner, but it requires SMS for login. Practically I can't log in. Passkeys, if anything, would improve on that, since we could have multiple passkeys.
The alternative to passkeys isn't passwords, it's passwords+SMS or passwords+TOTP, and they have worse UX and worse security.
I actually prefer the UX of TOTP because it makes the auth process visible—but I'm a weirdo. Admittedly it is worse security. But seeing the number in the text box gives me peace of mind because if autofill mysteriously stopped working (which it has), I know I could put the number in the box myself.
I put my passkeys on FIDO2 security keys. [...] Some use keepassxc, which stores them on local disk.
I'm glad you found something that works well for you, and may it continue to work well for you! But if the best practices are going to be "Buy a security key" or "install this special software", that's not great UX for 95%+ of users.
I actually prefer the UX of TOTP because it makes the auth process visible—but I'm a weirdo. Admittedly it is worse security. But seeing the number in the text box gives me peace of mind because if autofill mysteriously stopped working (which it has), I know I could put the number in the box myself.
That's fair. I suppose the goal is for it to be reliable enough that we don't seek out this assurance, similar to how in HTTPS/browser land, padlocks for HTTPS were replaced by warnings for plaintext HTTP.
I use password+TOTP for sites that don't support passkeys, and my weirdo worry is that the autofill origin logic can be tricked. Mutual auth (passkeys) satiates that worry for me at least.
But if the best practices are going to be "Buy a security key" or "install this special software", that's not great UX for 95%+ of users.
Indeed, 95% of users won't follow best practices. They use poor passwords, and if pushed, SMS or cloud-synced TOTP authenticators.
Synced passkeys is a security+UX win over that, and this is the main benefit.
Interoperability is poor, from testing I tried a week or two ago. CXP isn't supported yet, AFAIK. Third party interactions are not great, e.g., Bitwarden won't play nice with Windows' passkeys interface. Linux is definitely the poor cousin. Firefox seems to work OK with Bitwarden... other interoperability, including the BLE/QR code stuff seemed troublesome. My main usability concern is people getting stuck in one of the Big Tech provider's silos and then losing access to everything.
services should provide a way to recover your account
Whenever somebody uses a word like "should" you know that nobody is going to do this.
you are responsible to plan for its recovery
This is more or less impossible. I can come up with several scenarios from which no recovery is possible.
Passkeys focus on solving some of the simple problems of password authentication while totally ignoring the actually hard problems (which is a common refrain in software engineering). A technology that's deficient being foisted on users this hard, is evil. I can't describe it another way.
you know that nobody is going to do this.
Pretty much everybody does this. It's just the normal 'reset password' or whatever flow. It would work almost exactly the same way for passkeys.
I can come up with several scenarios from which no recovery is possible.
And others can come up with plenty of scenarios for password auth where recovery is not possible either. It's besides the point.
simple problems of password authentication
Passwords being phished today is the single biggest problem in cybersecurity. The fact that passkeys comprehensively solve this makes it mind-boggling that people don't want to use it.
totally ignoring the actually hard problems
If you are talking about account recovery, how can passkeys solve this problem for you? They are a decentralized technology, they can't magically back up your keys in the cloud and let you restore them with a recovery code or whatever.
Passwords being phished today is the single biggest problem in cybersecurity. The fact that passkeys comprehensively solve this makes it mind-boggling that people don't want to use it.
I think some people are worried that passkeys can be a DRM mechanism.
A password is inherently portable (this is it's strength and weakness), whereas a passkeys are granted:
To be very honest here, you risk having KeePassXC blocked by relying parties
https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994182200
I am skeptical on whether providers like KeePassXC will continue to be accepted in all places, but think there is enough mutual distrust that open hardware security keys will continue to be accepted. I don't think this is meaningfully different than my bank that requires a dedicated Android auth app, but it is crappy.
I'm not aware of alternative suggestions to address phishing.
If you are talking about account recovery
Yes. Passkeys are a way for these platforms to continue to operate with zero support. That's entirely what they are.
Wake me when the tech is reliable. I've already had two passkeys stop working, and I've probably only created a few dozen while testing them out. That's too high a failure rate for me to bother with yet.