The author still has one last misconception about passkeys, namely that if you lose a passkey, you have "no recourse."

People wrongly think passkeys are like Bitcoin wallets, where losing them means there's absolutely nothing you can do, your account is simply lost forever.

Losing a passkey is exactly like losing your password, which is to say, that for 99% of services, you can reset your password/passkey really easily. There's a prominent "Reset Password" button right on the login form. It sends you an email or an SMS, you click it, and it lets you reset right then and there. You can reset your passkey in exactly the same way.

It is not that easy to reset if you lose your password to your Apple, Google, Facebook, etc. They all have a bunch of factors that they use to authenticate you if you reset your password, and they don't even document which ones they use.

So, if you care about those accounts, you've got to make sure you have backup access. They all let you generate and print "backup codes" (emergency passwords) and store them in a fireproof safe or a literal bank vault. Do that!

As everybody knows, you can't store all of your passwords in a password manager. You need something outside of the password manager to login to the manager itself. That's why 1Password/LastPass is called that; you still need one last password that you keep and manage yourself.

That's true of passkeys, too. You can login to Google with passkey, but if Google is your password manager that stores your passkey, you need something else outside of Google's password manager to login to Google. Whether it's a password, a backup code, a YubiKey, whatever, you need one more thing to login to Google, ideally more than one, so you can back it up and keep it safe.

Pre-passkeys, was this lockout issue a true issue with apple and google accounts? Or have passkeys added a general lockout issue that didn't exist before? Also passkeys in their current implementation are not possible to back up or export yourself, unlike passwords in the past.

Security engineers are prioritizing preventing key copying over lockout issues, unilaterally, on literally billions of people. It improves their metrics internally, at the cost of an externality on the entire world. This kind of stuff invites odious regulation as more and more stories of lockout with no recourse surface.

And unlike passwords, there is no good provider migration story. There is a roach motel issue. Yes it is being 'worked on', but passkeys and such have been out for many years, the willful denial whenever you ask people running these standards about these issues is incredibly irritating. The fact they tend to avoid questions about this like politicians decreases trust in the motives of such standards.

> unlike passwords, there is no good provider migration story

I'm curious what the "good provider migration story" you're referring to here for passwords is?

Password managers by-and-large haven't agreed on a standardised interchange format for import/export - a few of them have some compatibility helpers for importing from specific popular competitors but they're all in different formats, no consistent formats.

The above goes for passkeys as it does passwords - import/export will include your passkeys - so I don't see much difference in the provider migration story.

On the other hand, the FIDO Credential Exchange Format does solve the above problem (if/when providers choose to adopt it), so passkeys are at least further along the path of creating a "good provider migration story" than passwords ever were.

Copy & Paste one at a time is at least possible with passwords

And what about password sharing? I want to share everything with my partner,in case something happens to me.

Passwords right now are outright better.

And by the way, door keys could be copied.

I agree. I use passwords with TOTP whenever possible. Passwords in a locally stored database (such as KeePassXC) can be easily shared. TOTP using Google Authenticator can also be easily shared, not just with my partner, but also among my own devices. Right now I see this as a much better, simpler, and much easier to understand option. BTW, the "easier to understand" is a big feature. Passkeys seem to be complex; just look at all the arguments about them in these comments. And where there is complexity there is vulnerability.

1Password family plan, and I assume similar cloud password managers, let you organize passwords/TOTP/Passkeys into vaults, and you can put credentials you want to share with other family members here.

You can store passkeys in a password manager where they're either in a full-time shared config or there's some configuration that allows access if something happens. (e.g. Emergency Kit for 1Password, legacy contact for Apple account, etc.)

Add your partner's passkeys to your accounts, then you can both login. Or put some Yubikeys in a safe that can be accessed if needed.

> Pre-passkeys, was this lockout issue a true issue with apple and google accounts?

Yes, absolutely. I have a second Google account I created and lost the password to. I can't reset it because it wants to know the exact month I opened it. I don't even know if it was 2012 or 2016, I'll never guess the month.

Yes. People have complained about the difficulty of Google or Facebook account recovery and how they need to make it easier and more accurate for ages. You could search hn for "password reset" or "lost password" and you'll find tons.

> passkeys in their current implementation are not possible to back up or export yourself

You can with KeePassXC, so it is a choice of the credential manager implementation. The standards people want to ban such credential managers though.

The primary credential a user relies on for logging in (whether it's a password or a passkey) is pretty unrelated to the the "lockout issue". The lockout issue is really the age old question of: what happens if I can't do a normal email-based account recovery flow (aka "I forgot/lost my password/passkey").

The answer to that is stuff like this:

https://blog.google/technology/safety-security/recovery-cont...

https://support.apple.com/en-us/102641

No, passkeys haven't added a new general lockout issue, because Apple, Google, etc. don't allow you to create an account where you can only login via passkey with no external authentication factor. They require you have something outside the Google account, whether that's a password, a hardware key, etc.

People keep falsely imagining that Google is setting people up with passkey-only accounts, with no way to backup their login credentials. Gosh, wouldn't that be terrible?

That would be like 1Password letting you create a passkey-only account with no password, storing the only passkey in 1Password. The whole idea makes no sense. 1Password doesn't do that, and neither does Apple, Google, Microsoft, etc. (We can all imagine them doing something that stupid, but, it turns out, they don't.)

Pre-passkeys, the most common lost-credential scenario was creating a fresh Gmail address on a new device (an Android phone) with a password and forgetting both your Google password and your password for your cellular-phone carrier (AT&T, T-Mobile, etc). Your Google password would be stored locally on your phone and in Google's cloud, but when you lose your phone and forget your passwords, no backups remain.

At that point, you're pretty much screwed. Google can't email you a reset-password link, because Gmail is your email. Google can't send you a 2FA SMS until you get a new phone with the same number, but you can't convince AT&T to do that, because they want to send a reset-password link to your email, which you don't have, or SMS to your phone, which you don't have.

(The cellular carriers don't even allow you to show government ID at a physical store. They don't allow you to take over a phone number that way, because people could then threaten/bribe a T-Mobile store representative to falsely claim that you presented valid government ID, taking over other people's accounts. If you walk into a store, they'll just put you on the phone with customer service, where they'll insist that you provide your AT&T password, or reset your password via email or SMS. If you've lost your email and your phone and all your passwords, you're completely out of luck.)

If Google allowed you to create a passkey-only account, with no SMS 2FA and no way to backup your passkey, that would be even worse.

But, luckily for all of us, they don't even allow that, and they're certainly not pushing it unilaterally on billions of people.

I use passkeys. I save them in the Apple cloud. They work on all my apple devices seamlessly. I don't need to copy them. Ecosystems are nice.

And what happens when Apple permabans your account for buying a gift card? https://news.ycombinator.com/item?id=46297336

Thumbs up!

I use passwords. I save them in iCloud. Or Bitwarden. Or Chrome/Firefox. Or Lastpass. Or 1password.

They work on all my (not just Apple) devices seamlessly.

I don’t need to copy them.

Non walled ecosystems are nice.

Good for you, glad you like it.

This is not a feature of passkeys, this is a feature of each and every individual provider building their own unique reset flow.

Not every provider does this correctly. Just yesterday I saw someone complaining on mastodon about their passkeys being locked and requiring a phone call to get reset.

Passkeys are exactly as resettable as passwords, which depends on your provider actually implementing things correctly.

tbh I think it's safe to claim they're strictly inferior to passwords, though in almost all cases they're literally identical (as you point out).

e.g. that phone call case: some places will tell you a temporary password (over the phone) to enter next time, and then you come up with a new one when you log in. there is no equivalent flow for passkeys, because you can't enter them by hand. a site could of course build that for passkeys (like a temporary password with special UI for entering it), but literally every site with passwords can do that by default, it just needs a general admin UI which almost always exists.

(most I've encountered will email you a temp password, and in principle you could email a temp passkey too... but that doesn't work by phone / for manual entry, and is there a spec on that file format? I don't think so? in your password manager right now: is there a place to manually import a passkey for a website? half of mine don't have one for passkeys, but every single one I've ever seen has a way to manually enter a password)

> but literally every site with passwords can do that by default, it just needs a general admin UI which almost always exists.

Most sites/systems that are designed for security won't have such an admin UI - passwords should generally not be handled in a way where anybody other than the user is ever able to know what they are.

"I can erase a securely hashed password and set a new one" is very common and generally seen as safe, and does not at all require being able to "know what [the current password is]".

Most can do this. As a concrete example, phpMyAdmin has UI specifically for editing password fields: https://www.wpbeginner.com/beginners-guide/how-to-reset-a-wo...

Apple and Google often store your other 99% of passwords and passkeys, so losing this is actually more important than losing the 99%. I take your point but saying 99% have reset services when the critical 1% may never be recoverable without posting to HN is an important point.

For those you add recovery e-mails. You can easily have a Google, Microsoft and Yahoo e-mail so having access to at least one means you can recover the rest. Yes, this increases your attack surface, but the chances remain miniscule.

Just as a note: for E2EE services that use your password to decrypt your key to decrypt your data, a recovery email often recovers your user account BUT not your data (so you may get access to a blank account). It is perfectly possible to lose access to your data, that may include the rest of your passwords, if you have not set up other recovery methods which can actually decrypt your encryption keys, and rely on a recovery email or phone.

Also, just so I'm clear, there's no requirement to share passkeys. Or even have passkeys enabled on all devices, right?

If I log in to a site from my machine, and set up a passkey, but then log into that site from another machine, it'll just see no passkey present and ask for my password, yes?

A passkey is a local password on a device that could be shared through all the password manager gymnastics, but its not required as I understand it.

That’s true for all accounts that i’ve been using (Google, Apple, Microsoft).

Passkey generated on a device can only change login flow for this one specific device. If you don’t synchronize passkey to other devices or if you do not generate passkey on other device, then login flow is different for other device. You need to enter password.

Imo it would not make any sense if it was different.

I think there are passkeys that can be migrated/synced between devices, and device-bound passkeys that can't. I do save passkeys on my password manager and use them across devices, but I am pretty sure I have had passkeys that I could only use from a specific device. Not sure though, it feels a bit confusing.

Yes, that's right. It might also make sense to generate multiple passkeys for an account. For example, a separate one for logging in from Apple devices.

some sites actually let you use a passkey on another device to login. AWS is one.

in that case, passkeys are pretty useless considering that they can be bypassed by the other factors they were designed to eliminate in the first place.

Sure I'm super secure using a passkey.... except that there's always a "try another way" option on the login screen. Which defeats the purpose.