[zoomTo125]

There are still a lot of questions I'm not clear with passkeys. How do you recover your keys if you lose your hardware? What happens if you lose your phone and have no extra trusted device? There will be no more phone number, and no more trusted device. Most MFA implementation, which heavily rely on phone number, will no longer work. And, for Yubikey, how do you backup? Do you need multiple Yubikeys? Do you need to manually make a copy of every keys? How do you know if the copy is synced with the main one?

[dfabulich]

It's way simpler than you think. You reset your passkey the same way you'd reset your password.

So, how do you reset your password when you forget it? Well, it depends.

Some apps/sites just send you a password reset email. Apps/sites like those would reset your passkey the same way: they'd send you a passkey reset email, you'd click the link in the email, and they'd let you regenerate your passkey then and there.

Some apps/sites try to do something cleverer, e.g. requiring additional factors to reset (MFA), or appointing a "trusted contact" user who can confirm your password reset, or asking "security questions" that only you know the answer to. Those apps/sites would put you through the same process to reset your passkey.

"How do I reset my password when I forget it" is an infamous balancing act between user friendliness and strict security. The "reset my passkey" problem is exactly as hard, no easier and no harder, as the "reset my password" problem.

(Of course, it's possible to have a site that has no way to reset your password, and just assumes that you'll never forget your password. Similarly, those sites could have no way to reset your passkey. In that case, the problem is as you say: there'd be no way to recover your keys if you lost access to them.)

[NikolaNovak]

>>So, how do you reset your password when you forget it? Well, it depends.

But I don't! I can write a password in any amount of low and high tech ways! I have them printed on paper in safe deposit box (my wife is bad with passwords, so this is safety if I should perish:), I have them in a password manager on USB sticks at home in a safe, I have them copied on my NAS and laptop and so on.

Whereas passkeys, it seems from everywhere I read to be far more fragile, far more locked in to specific perishable hardware device and a specific vendor ecosystem, and very limited or no ways to handle passkeys in a low tech way or as a file/artifact to be backed up. Basically they assume I live on and with my phone.

To put it bluntly:

Passwords are something I can use if I show up naked at a stranger's house. They can be with me in and through an emergency (physical emergencies exist! Computer geeks forget about those!). Or more commonly, I can use them to check my email or comms if I forget my phone at a friend's house.

Passkeys are... strictly worse?

[stavros]

You can do this with Passkeys. You can write your Passkey down on a post-it, or memorize it and cross the border with it, or anything you want.

This thread has urged me to write a post clarifying some of the misconceptions I always see:

https://www.stavros.io/posts/clearing-up-some-passkeys-misco...

[derbOac]

That was helpful but there's a difference between "possible" and "feasible in practice for the vast majority of users". Eg, you can theoretically develop your own passkey device as you say, but that doesn't mean most people can.

I'm not sure I really prefer passkeys less than passwords but I do think some of the "misconceptions" aren't really misconceptions, but realistic concerns about what happens in practice. It might be better to be up front about these than dismissive, because that's where the problems in practice develop.

[stavros]

But you don't need most people to develop their own Passkey device any more than you need most people to make a phone.

A company will make it, vote with your wallet and buy the one that suits you.

I'm looking forward to BitWarden supporting Passkeys, for example, as that's my preferred way of using them.

[zamadatix]

If I have an iPhone, Mac, Windows PC, and Android Tablet I want to know and talk about what I can do with Passkeys, not what could theoretically be done. After all, I'm not looking at Passkeys for an academic exercise. I'm actually looking to see how feasible it is for me to use Passkeys to replace my passwords today.

If that means "install BitWarden on all of your devices. The devices will work with it and you can backup/export your key locally" that's fantastic, I'd love to see a guide on how to get that going on all of my devices. However, if that means "according to the standards, something like a BitWarden could do what you want it to do, if they built it, allowed export, and the devices all allowed integration. Alternatively, you replace your devices with ones that do." then I really don't care what the theory says could be done, Passkeys cannot actually replace my use of passwords at the moment.

[perryizgr8]

> You can do this with Passkeys.

Maybe in theory. In practice, I couldn't even look at the passkey Google has created on my android phone. So you absolutely cannot write it down.

[stavros]

If you don't like Google's implementation, you should use another one. It doesn't make much sense to say "I can't do X with my thing, therefore I can't do it with anything".

The fact remains that, if you want a Passkey you can write down, you can do that.

[perryizgr8]

> If you don't like Google's implementation, you should use another one.

Once more, maybe this is possible in theory. In reality, I can't find any way to use apple's passkey implementation on my android phone.

[masfuerte]

That's really helpful. Do you know of an open source passkey client?

[stavros]

Someone has linked a few implementations in the thread here:

https://news.ycombinator.com/item?id=36238001

[brookst]

Thank you. It is disheartening that so many HN readers would rather imagine how passkeys work, and freak out at their own imaginings, than just learn the real thing.

[NikolaNovak]

Somewhat fair criticism, but also somewhat unfair. A lot of us are trying to read up and understand, and so we post questions in forums like these with knowledgeable folks, in hopes to enhance our understanding and reduce our concern.

One counter point though is that... if there is a new lifesaving technology, and even the somewhat IT literate / somewhat geeky / folks who WANT to understand it, are struggling... it may not be as simple and easy and safe. If I ask "how do I backup my passwords", I'll have 10 million folks answer "use a password manager, backup the file". When I ask similar questions with passkeys, the breadth,inconsistency and complexity of answers is as insightful as it is worrisome.

[brookst]

No complaints with questions, but many of the questions are in the form of assertions that are incorrect.

"Does that mean that passkeys can't be shared between users or devices?" is a 100% reasonable question.

"Passkeys are a step backward because they can't be shared between users or devices" is not really a question, it's an opinion based on imagination.

And passwords are just as complex. How do you securely share a login with another user?

Yes, there's complexity, but it's complexity born of a change in paradigm. The actual new thing is either equally simple or simpler than traditional passwords, once you factor in scenarios like backup, transfer, multi-device sync, sharing, etc. It's just different.

[stavros]

Yep, that's what frustrates me as well, especially for a technology that will be a massive gift to both security and usability.

[barbazoo]

Have a look around this thread. Lots of smart people having difficulties figuring out how this works. This is a bad sign. It shouldn't be this hard to figure out the basics.

[makeitdouble]

I've spent about 10 minutes Googling, and I'm still not sure how I backup and restore passkeys.

I use a password manager with a full backup of the vault, so the answer to most of the parent's question would be solved by getting the vault back from backup. Except:

- passkeys are not yet supported by my password manager, so I'd have to wait for a while

- can I move Safari's passkeys to my password managers afterwards, like I did with passwords ? probably not ?

- can I move my password manager's passkeys to another one if I need to ? I have no idea.

That's where, at least for me, none of this is simpler than I think. The same way reset passwords is an absolute last ditch effort, I hope passkeys can be managed without having to get back to the service every time we change how we want to manage access on our side.

[dzikimarian]

You can set up as many as you want, so just register your phone as one and your PC as other. Eg. using Windows Hello. If you loose or compromise one device, you just delete it as a passkey - rest is still working. If you loose all of them at the same time somehow, there's usually fall back to password or some kind of reset process.

[NikolaNovak]

For every account thought, correct?

Like, I can keep all my passwords in a password manager. And then copy and replicate that database however I want to.

With passkeys, I'd need to set up and authenticate additional devices... for every of hundreds of accounts I have? Am I wrong? Like if I have an android tablet and iPhone and windows PC and a Linux PC (as I do) that's half a dozen setups for each and every account? And this is a good thing??

[MilaM]

It's my understanding that passkeys that are created by platform authenticators or password managers can be backed up. That's how replicating your key through iCloud likely works. Hardware keys on the other hand don't support backups by design. You need to enroll multiple keys to have a backup.

> With passkeys, I'd need to set up and authenticate additional devices

This is true, if you don't use a platform authenticator or password manager and only use hardware keys.

[dzikimarian]

As mentioned by other you can use solution, that propagates your passcode credentials across devices - probably most password managers will offer this soon. I wouldn't, because you loose separation in case of compromise of one device, but if you do - it's still on par with security level of today's password managers with cloud sync.

Also you don't really have to set up everything everywhere all at once - passwords still work and you can use phone passkey on PC via QR.

[throw0101b]

> I've spent about 10 minutes Googling, and I'm still not sure how I backup and restore passkeys.

In the Apple ecosystem your passkey is / can be sent to your iCloud Keychain, which you can restore when you can a replacement device (and keep using on non-lost/stolen devices):

* https://support.apple.com/en-ca/guide/iphone/iph82d6721b2/io...

* https://www.google.com/search?q=apple+passkey+icloud

[gcr]

This doesn’t address the issue if OP needs temporary access via an Android device.

[selykg]

If you still have access to a device that can handle the passkeys then you can use the scan of a QR code to gain access.

If you do not have access to a device with your pass key on it then using iCloud Keychain is probably not the best service to use for your use case of an Android device. Use one of the many other services that also provide Android support and passkey support. Then you can access that service and access your passkeys.

iCloud is one of many. Bitwarden and 1Password will both support passkeys, both have Android support.

[makeitdouble]

Yes, Bitwarden's pass key support is for "this summer".

https://bitwarden.com/blog/bitwarden-passkey-management/

[jiggywiggy]

I don't know about Windows, but if you see the example your Mac is putting it in your keychain app, which is usely available on other devices that are connected to your Apple account. Also if you install a new macbook. Most likely also on your iphone. If you have an Android phone that will be a lot less smoot

[makeitdouble]

I had the impression that Apple stores and syncs them for you, but at no point will give you the option to actually backup or restore (have a copy of the info under your management). Let's say I need to move a credential from my account to my wife's, I guess it's probably not allowed. Or god forbid I change Apple IDs.

[brookst]

https://developers.google.com/identity/passkeys/faq#how_can_...

[weikju]

You can export your password (from Safari or from the Settings app) to a csv file. Not sure how that handles passkeys, if at all, however. Probably not (yet).

[PhilipRoman]

The email password reset feature is an overlooked part of modern security. It has become sort of like a master key for every service. Combined with password reuse it becomes really risky (but oh, so convenient).

[drdaeman]

This approach basically makes all the security provided by the passkeys void, as the whole system becomes no better than login-via-email-link or login-via-SMS-code scheme.

[fshbbdssbbgdd]

Every time an average user registers to a site with a passkey, they aren’t giving that their reused password that also provides access to their email (I believe that’s the main way email accounts get hacked).

If they registered to their email with a passkey, great.

Either way, passkeys seem to reduce the risk of the email being compromised.

[drdaeman]

I don't think password reuse is the common vector - I believe the most common one is phishing, where user is tricked into giving up their current credentials, straight for the service that attacker is interested in. But I can be wrong. And, yeah, it is an improvement for sure.

You're definitely right that passkeys drastically improve the bottom line security for the least protected folks (which are probably the majority). It is a step in the right direction, for sure. But they also make things worse for me - someone who uses different random high-entropy passwords for almost everything except local sudo and unlock PIN codes. I want to use PKI instead of shared secrets, but when I try - it's extremely inconvenient, so I know at some point I'll just give up. This, and the fact that my bottom line is not moving up at all - it still remains the same, limited by recovery processes' security - is frustrating.

[kahnclusions]

How do I access my e-mail to reset my passkey when it's also protected by passkey?

[Technotroll]

I had this problem with Dashlane after they suddenly changed their policies, though with a regular password. My solution? Out of frustration I developed my own password manager. Eventually I was able to recover the password from my email provider though. But at that point I had no more nails left.

[dicytea]

I had the same issue with LastPass a few years ago. When I reinstalled my OS they decided to lock me out of my account because they thought I was a different person. The only way through is e-mail verification. Guess where that email's password was stored in?

Lost everything. Been using Bitwarden ever since.

[ursuscamp]

Everyone must know two passwords: their password manager's password, and their email password.

[jaden]

It gets even more complicated if you use 2FA with your email provider.

[ayewo]

> I had this problem with Dashlane after they suddenly changed their policies,

This is a bit hard to know what to search on. Where can I read more about the policy changes?

[Technotroll]

Sorry, I can't remember. They suddenly lowered the amount of clients a few years ago. This locked me out of my e-mail client. Since 2FA updates were sent to my e-mail it lead to a bit of tail-biting. Pretty much the same problem can happen with a passkey. Either way this blew away a lot of the trust I used to have in password managers, so out of frustration I coded my own as a backup that can digest Dashlane output so I never need to rely only on them ever again.

[jjav]

> (Of course, it's possible to have a site that has no way to reset your password, and just assumes that you'll never forget your password. Similarly, those sites could have no way to reset your passkey. In that case, the problem is as you say: there'd be no way to recover your keys if you lost access to them.)

Isn't this the catch though (I haven't been following passkey work much)?

Every site knows users will absolutely forget passwords, so having a reset mechanism is a must. But I can imagine many sites thinking nobody will forget a passkey since it doesn't need to be remembered, thus hardcoding it in ways that make reset impractical.

[drdaeman]

There's more. Password recovery means that you're changing your password. Every single password reset flow does what it says on the tin - resets your password. After it's complete, old password is gone, account has a new password. This is logical.

For Passkeys, going through the recovery flow may indicate two possible things: 1) that you lost the Passkey and going through the recovery to replace it with a new one; or 2) that you merely want to log in on a different device where the original Passkey is not available.

This, of course, is going to work in practice - much worse designs had worked after all. But it's all logically unsound, and not really addressed by standard bodies or large implementers. It's not a big deal and there are ways to make it logical - but because it's not addressed it's gonna be a mess.

[hartator]

> Some apps/sites just send you a password reset email. Apps/sites like those would reset your passkey the same way: they'd send you a passkey reset email, you'd click the link in the email, and they'd let you regenerate your passkey then and there.

Sounds like email based login with extra steps then.

[raxxorraxor]

Not really sure if that is really cleverer to be honest. I think passwords and the common password reset via capability URL is pretty fine. I use stronger credentials for banking and everything else is pretty much only protected by password. I also do cherish the privacy advantages of not using a login provider. I had accounts suspended for no reason and this dependency is just not acceptable.

Even banking with device bound credentials is a hassle everytime you switch devices or you picked up the wrong phone.

I have some apps using login with Microsoft because users are logged in anyway in a corporate environment and it is practical to provide SSO. Here accounts might also be closed and access needs to withdrawn. Practical to do so centrally.

But for cleverness I still believe nothing beats a secret in your head. Quick, fast, secure. Oauth is a mess, so I doubt passwords will be outdated anytime soon.

[zoomTo125]

Thank you. I think this answers my question.

[aetch]

The passkey people won’t give you a straightforward answer because you won’t like the answer.

If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”.

If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to login on a new device or IP without your phone. But if email was the recovery method it’s just the same as sms 2FA which is reasonably secure and fail safe for the average person because there is a trusted third party in the loop…

[stavros]

> If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”.

That's an uncharitable interpretation. A more charitable way to say this is:

You can choose between secure/uncloneable and less secure but more flexible. Passkeys let you make the choice and don't dictate it for you. Choose whatever better suits your use case.

EDIT: I've written a short post to clarify a few misconceptions:

https://www.stavros.io/posts/clearing-up-some-passkeys-misco...

[jasonjayr]

Who gets to choose?

If it's the user, how do I as a user choose right now?

If it's the service implementing passkeys, why wouldn't they force a solution that's easier for them (less testing/less support/less maintenance, by forcing attestation to a specific list of providers), instead of letting users have an option?

Passkeys are an awesome solution to a difficult problem. But they are one bitflip away from eliminating user choice. Fix that problem, and I think folks here will jump on it in a hearbeat.

[stavros]

The user gets to choose. When enrolling an authenticator, you can choose what the authenticator is. I don't like Google's, so I use my phone and my Solo 2 as authenticators.

[segmondy]

So here's how I implemented the recovery in my proof of concept. Your backup is performed using your backup private key, and the encrypted passkeys (private keys) are backed up to the server. If you lose your device, you obviously can't login and need your back up private key to recover. I implemented shamir secret sharing, it splits your passwords and you select from your contacts (other users who will agree to serve as your backup). So let's say you have 4/7, that means 4 people out of 7 people is all you need to recover your private key.

When you lose your device and reinstall the app. It asks you if you are recovering or a new user. If you select recovering your key. We will generate a new pub/private recovery key. Remember we are assuming you lost your phone. The app will then ask you to enter the phone number of the 4 people that will vouch for you. When you select those 4 people, a call is initiated to them where you must read off a code that the restoration server gave to you on your new device, they will then select that they are vouching for you. The idea is that these are your friends or people you trust. You have to convince them. Not just automated think. At that point their phone will send the pass key fragments to you (encrypted using your new pub key). When enough people give you the info you need. Your phone will decrypt with your recovery private key and then recover the backup private key.

It will then request the encrypted backup from the server. The server will provide it with the encrypted back at which point it will use the recovered private key to decrypt the backup and recover all pass keys.

[systemvoltage]

> The passkey people won’t give you a straightforward answer because you won’t like the answer.

Well, then this culture needs to be condemned strongly.

[junon]

Why? Security isn't an opinion, it's a science and art. It doesn't care about what you think of it.

Perfect security leaves no room for user friendliness. The most secure system allows no users to use it. Only by reducing security do you gain user friendliness. The most user friendly (as in, triviality of use) system requires no security.

The art comes in when trying to create more usability whilst giving up less security, of course.

Passkeys are more secure than passwords. Thus, it's only natural they are less user friendly. If you don't "like" that, then stick to passwords. There's nothing to condemn, however.

[PeterisP]

Availability is a major part of security (confidentiality-integrity-availability etc), so a process that has significant risks to availability can not be considered secure.

[hooverd]

I like the part about passkeys where they avoid having a shared secret. Not so much the platform lock in and creeping remote attestation. Oh, don't worry, it's just in the spec, we're not going to do anything with it... yet. Seems like they're gunning for a world where if you're not using a blessed Microsoft/Google/Apple device you're locked out of it.

[Izkata]

> Security isn't an opinion, it's a science and art.

The art side is where opinion lies.

[JohnFen]

> If you don't "like" that, then stick to passwords.

But the passkey crowd is overtly aiming at eliminating passwords.

[starttoaster]

And I wish them luck. At least in my country (the same one I assume many of you also live in) our financial institutions haven't even implemented non-SMS MFA options yet. Literally the systems with the most impact on our daily lives (because they hold our money) haven't even stepped up to the security available in 2016 yet.

[sanitycheck]

If a "reset passkey by email" option exists, they don't seem much more secure than a unique complex password + (non-SMS) 2FA.

So for most people on HN (who also probably won't be successfully phished) they offer only new problems, yet if implemented and used widely they're probably a net positive.

It's a bit like the Covid rules. I am more than capable of avoiding other humans without new laws, but "normal" people seemed to need a lot of coercion.

Personally I'll give it a few years and see how passkeys pan out before I switch (if I get the choice).

[systemvoltage]

God help us if people here think "Security is art".

We are screwed.

[Wool2662]

Recovery is the same as with passwords. Depends on the services policies.

Passkeys and YubiKeys are different things. But generally it is recommemded to have a second YubiKey in a safe place and to register at least two keys on every service. Unfortunatly the implementations for using hardware keys are often pretty bad and require to activate alternate MFA which defeats the purpore of having a hardware token in the first place.

For backing up a yubikey. If you manage it you get a massive bugbounty. The whole purpose of a yubikey is to not be able to read the embedded key. Yubikey guarantees physical posession of the key itself if you can prove knowledge of the key within.

For passkeys: Only the authentication/creation process is specified. How passkeys are stored, shared, backedup etc is totally up to the implementing party. So Google and Apple will synchronize the keys using their existing password infrastructure.

In the end the only difference to passwords is: - It is always randomly generated - You can have multiple passkeys per service - The application managing passkey is required to verify that passkeys are only transmitted to the service they were created for (making them phishing resistant)

Passkeys are basically the point between passwords and hardware tokems like the yubikey. Safer than passwords and less safe than a yubikey but easily usabale by everyone.

[skybrian]

This will vary depending the provider, but you could think of passkeys getting synced between devices in much the same way that saved passwords get synced.

Apparently Google's implementation stores an encrypted backup of the passkeys in your Google account [1]:

> A single passkey identifies a particular user account on some online service. A user has different passkeys for different services. The user's operating systems, or software similar to today's password managers, provide user-friendly management of passkeys. From the user's point of view, using passkeys is very similar to using saved passwords, but with significantly better security.

[...]

> In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.

> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. Note, that restoring passkeys on a new device requires both being signed in to the Google Account and an existing device's screen lock.

So, if you use Google to store passwords or passkeys, it would be a good idea to save backup codes for your Google account somewhere safe. (Like you should do anyway.)

[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...

[makeitdouble]

> So, if you use Google to store passwords or passkeys, it would be a good idea to save backup codes for your Google account somewhere safe. (Like you should do anyway.)

Alternatively, if you're locked out of your Google account, these passkeys are also dead as the encryption keys are bound to the account. And passkey reset through email for instance would also probably out of question if it was your primary email account...

People should think long and hard about what services they assign passkeys with their Google accounts, it's a lot more binding than plain password or standard 2FA was.

[skybrian]

Yes, if your threat model is "what if Google locks me out?" Then you won't want to rely on a Google passkey as your only way of logging into a website.

Ideally, websites will support multiple passkeys per account. I think having both Google and Apple passkeys would be sufficient since I think I would be unlikely to be locked out of both.

Apparently Tailscale doesn't have multiple passkeys per account, but they recommend creating a backup admin account, and you could use a different kind of passkey for it.

[martin-adams]

I replaced my iPhone in-store and they transferred all my data. All my data except my Google Authenticator codes.

I lost access to at least one account as a result and had to submit identity documents to recover the account.

I now make sure I have backup codes stored somewhere.

Interestingly, in the past couple of weeks, Google Authenticator can now back up to your Google account.

[tough]

Authy is a nice alternative to google's Authenticator

Was bought by Twilio, but still rocking.

I love the plugin for raycast.app for it

You set a master password and can login back with your phone number/master password in any device

Much easier to not fuck up 2FA with it when changing phones

[yrro]

FreeOTP is another alternative - passphrase-encrypted backups can be saved to local or cloud storage and imported to FreeOTP running on another device.

[snagg]

The short answer is that it's non standard and it depends on where the passkeys are stored. To be precise, the original WebAuthn standard did not account for a recovery mechanism at all and instead recommended adding multiple credentials to an account.

Practically if the passkeys are stored in your iCloud Keychain, they are automatically synced across your Apple devices and the recovery mechanism is the recovery mechanism for iCloud.

Similar consideration for Google/Chrome and other password managers.

We wrote a relatively long blogpost about this + implementation and threat modeling considerations in case it's interesting: https://www.slashid.dev/blog/passkeys-security-implementatio...

[decryption]

You need to add multiple passkeys so if one breaks, you can still access the service.

Ditto for Yubikeys (which can be added as a passkey), you need more than one so if you lose it you can still access.

[drdaeman]

Which is going to be a major pain in the ass.

Every time you sign up for something you have to perform a complex rite: 1) sign up or add a portable authenticator (Yubikey or software token in something cross-platform like 1Password); and 2) run around the house, grabbing up all the different devices you have that aren't transparently synchronizing (so, something from Apple, something from Microsoft, something from Google, and don't forget that backup Yubikey you have in a safe too) and enrolling them on the same website.

I'm baffled how this obvious issue is not just unsolved at the start, but is not even addressed by any user-facing marketing materials. Every single demo stops at enrolling one single device, period. The word is that vendors will do you good magically letting you access that passkey from everywhere - and they missed that huge fucking asterisk after "everywhere". Because they won't - Google, Apple, Microsoft, 1Password, and probably everyone else have no incentive to do so, they want to stay in their respective ecosystems and no chance in hell they're doing any cross-platform interop with anything that not theirs.

Apple, Google and Microsoft would love this model. People suddenly swayed to stay within their ecosystem to log in to websites. "Oh shit can't login from here, gotta start Microsoft Edge to access this website" sounds exactly like what those corporations fancy.

Yubico and 1Password don't have a beef with it - someone wants a portable authenticator, they're gonna pay for it - it's not like there are many options anyway.

And only me - as an end user - is not exactly happy. Even though I do want to get rid of passwords and replace them with keypairs.

---

Add: This said, if you're at some conference attending a talk about Passkeys... Please consider raising this point and explicitly not letting it slide with the usual waiver of "nothing to worry about, $VendorName will sync the Passkeys across your devices". Raising awareness is important.

[stavros]

I don't understand the issue here. Passkeys are just a way for a site to ask your browser for credentials. If you don't like the current solutions, write your own, and it'll work with all Passkeys-enabled sites. Why do you need the standard to be different?

[drdaeman]

> If you don't like the current solutions, write your own

Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own? I don't. Do you think it is realistically (and not theoretically) possible to implement a new solution that would provide the security properties as good as sum of all individual fragmented options? I'm not sure. And even if someone spends enormous resources and makes it all real, there's still that issue of a Yubikey in a safe.

Sorry, but if N implementations require that inconvenient process I've explicitly outlined, having N+1 option still won't fix it.

And it's the standard's fault, not "the implementations aren't there yet". The standard had not addressed this, even though it's pretty much obvious this is going to be an issue on the very first day someone who isn't an ideal customer (100% lifetime loyal to one single vendor) uses Passkeys.

When I'm setting up SSH keys on a host I can either give it a list of all my keys, or CA certificate to trust, but I don't have to grab all the individual devices. Here, I must.

Attestation is another potential issue, but it's not a problem today.

[stavros]

> Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own?

Yes, given that I use my open source Solo 2 to log in to any Passkeys-supporting site already. It's not about whether they will support it. It's an open standard, you can use whatever you want.

[drdaeman]

This means you have one single Passkey system. I'm talking about multiple Passkey systems and that there is no way to make it work without a very inconvenient process.

Three arguments:

1. Redundancy and failover. Without backups, "if I'll lose access to that account" is not even a question, "when" is. Unless you have a second Solo 2 in your safe - some day, you will lose that account. You may be able to recover it, of course, but that's another story (a story of security properties of your account and ability to access it without having credentials).

2. Availability. If some device (e.g. an iPhone) won't support your Solo 2 (e.g. you don't happen to carry that Lightning-to-USB-type-A adapter) - you don't have access anymore, even if you have your key with you.

3. Convenience. You may log in only with your single Solo 2 key, but you'll probably want to be able to log in to your websites from your phone, without having to walk to your desk (even if for a few feet) to grab the physical key for every single new website.

I can think of a scenarios where you won't hit those limitations. The problem is, they're not some weird ass case for silly nerds - they're real situations that are gonna happen to your average Joe (but he, unlike nerds, won't really think about those until they happen).

[JohnFen]

Writing your own is only an option as long as everyone ignores attestation. Which might be what everyone does -- but the standard absolutely supports attestation, so there's no guarantee.

[stavros]

I don't see attestation as such a big problem. If a site doesn't support your (perfectly compliant) client because of attestation, complain to that site so they know they lost a sale because of it. Companies aren't willing to lose customers for no reason.

[JohnFen]

> they know they lost a sale because of it.

Most of the sites I worry about aren't commercial in nature. They aren't getting "sales".

But I'm not going to complain to any company-run websites about anything anyway, because the odds are overwhelming that they simply don't give a shit. That's been my experience over years, anyway.

Small human-run websites are a different matter. They tend to care quite a bit. But they're also the least likely to stop accepting passwords.

[drdaeman]

> Companies aren't willing to lose customers for no reason.

If only companies would've known this... Can you please start by explaining this to the infamously ass-backwards banking industry? ;)

[rebeccaskinner]

I see a lot of claims that passkeys are more secure than passwords with 2fa, but my understanding is that they are strictly less secure. As it stands right now, if someone wanted to compromise a service that I use 2fa with, they'd need to both obtain my physical device, and also get my password. Either one of those things may be relatively easy, but it's harder to do both- especially without my knowledge.

With passkeys, if someone steals my physical device, then they have full access. That seems strictly worse to me. It's just beyond me how there's a plausible claim that moving to a single factor is better than two factor authentication, except that it gives Google and Apple more control over the internet by allowing them to lock people even more heavily into proprietary OS ecosystems.

[aniforprez]

> With passkeys, if someone steals my physical device, then they have full access

Unless they also have access to your fingerprints, face or something to that effect, they do not have access to your device. Every time I create a passkey, I am required by the device to provide authentication. I'm not sure if this is a hard requirement because all my devices have PINs, passwords and fingerprints but I assume that your device needs to have some form of security for passkeys to even work. In 1Password's demo, I had to authorise every individual login call with my system PIN on Windows and fingerprint on Android

If you don't use biometrics and use a pin/password and the attacker has access to both your device and this information, then there is no difference to how it currently operates because the attacker already has all the info necessary to take over your accounts. If an attacker has your device AND access to biometrics, then you have bigger problems

[crote]

Biometrics are not a technical requirement for passkeys, so your security model cannot rely on them being used. Moreover, as history has shown, the biometric security model is most likely flawed as your device will be covered in copies of your fingerprints anyways. It's a huge single-point-of-failure.

The "traditional" security model of a password vault on a computer and a 2FA token on a smartphone requires both devices to be compromised, Theft of either device is pointless, and even the theft of both is often insufficient as the password vault usually requires a passphrase.

[rebeccaskinner]

As far as I can tell, biometric authentication is locked to proprietary operating systems. On Linux with a yubikey, for example, it seems like you're not only limited to only 25 sites, but you're also at best going to have a pin, and in many cases the hardware alone may be sufficient to gain access. Sure, you need to know what site the key has been registered with, but I'd bet if you found a random key at a conference you'd have pretty good luck trying it with google and github to start with.

edit: after some digging (which was a lot more involved than it should have been) it seems like the current state is:

There is free software to set and manage a pin for a yubikey on Linux. Firefox historically didn't support yubikeys with a pin, but it seems like that was recently merged. Yubikeys still have a 25 site limit per device, and no sync across devices. As long as sites let you register multiple yubikeys as a backup, and support pins, then it's a reasonable workflow. I'm not convinced it's better than passwords + a yubikey for 2fa, but it seems like in practice it's probably not worse either. It still feels like, even if security is a motivator here, there's a lot of opportunity for Google, Apple, and MS to conveniently and "accidentally" cut free software users out of being able to access a lot of the internet with the move to passkeys, and I remain skeptical.

[aniforprez]

Passkeys are not the same as biometrics. Passkeys are generated and stored locally but do not have to be generated or stored on your device. Password managers are already moving towards supporting storing your passkeys. While you could store passkeys in your Yubikey, the ideal scenario would be your Yubikey is your authentication mechanism for your device or password manager and disconnecting your yubikey will lock down your device and password manager. This way, the attacker needs your Yubikey and your device for gaining access. If you set a pin on your Yubikey when you connect it to a device, that would probably increase the security. Personally, I am eyeing something similar to the fingerprint scanning Yubikeys for my own purposes. But until then, using biometrics on my systems is sufficient. 1Password is also moving to passwordless passkey access at which point my flow would be

1. Unlock my device with a pin/fingerprint/face unlock

2. Unlock 1Password with this same mechanism

3. Unlock access to a passkey supported website/app using 1Password which will store my passkey for that website/app

Through all of this, an attacker would have to have access to my device and my device authentication mechanism for gaining access which still counts as 2 factor

[Izkata]

> > With passkeys, if someone steals my physical device, then they have full access

> Unless they also have access to your fingerprints, face or something to that effect

Fingerprint scanners are a lot better than they used to be (back when they could be beaten by a gummy bear), but what about a picture of your face?

Biometrics should be thought of as passwords that can't be changed. Use them for convenience, not security.

[sgk284]

> if someone steals my physical device, then they have full access

Apple protects passkeys via FaceID or TouchID. If you're satisfied with biometrics as a 2nd factor, then there is no regression in your scenario.

[Double_a_92]

But that's an extra thing that Apple does to store the passkey locally. It's not an inherent property of the passkey system.

Also that then leads to the situation that your passkeys are completely locked inside Apples ecosystem! (Or Googles, or Microsoft, or whatever...)

[als0]

Physical devices, like Yubikeys and iPhones, have rate limited PINs. It’s not enough just to steal a device.

[mceachen]

In my testing, access to your passkey requires your _unlocked_ device (as opposed to a yubikey, which has no on-device authentication)

[freitasm]

Except the Tailscale implementation doesn't allow you to add more passkeys to an account. There is no "one account multiple keys" here.

[ptman]

That is a very big omission.

[zoomTo125]

Not really. It is in the article.

[zoomTo125]

What happens if some websites don't allow you to add more than one passkey? Now, you need to keep track of which site has backup key, and which site doesn't have one. Also, the website needs to store multiple public keys now.

[gabeio]

> What happens if some websites don't allow you to add more than one passkey?

Do you know of any which currently only allow one passkey?

[woodruffw]

I don't know about Passkeys specifically, but this is unfortunately common enough with WebAuthn rollouts.

I'm not sure if it's true anymore, but Twitter for years only supported a single WebAuthn token.

[dinvlad]

I think even Amazon does that too still, such a shame

[JimDabell]

If you’re referring to AWS, they added support for multiple MFA devices last year:

https://aws.amazon.com/blogs/security/you-can-now-assign-mul...

Amazon’s shopping site also lets you set up multiple devices, but I’m not sure when they added that.

[freitasm]

Tailscale only allows one passkey it seems.

[n42]

no, this is false. this is different than 2FA. you can reset your passkey just like you can a password.

[freitasm]

You can if there is a provision for that. As mentioned before it doesn't look like Taiscale allows you to either have more than one passkey or reset the passkey.

[n42]

hm. I guess these are the early days for the industry where providers are figuring this stuff out. I won't be surprised to see them add that. yes, you can lose keys, even (especially) if they are digital!

[taberiand]

Those issues are applicable to using password management tools generally, rather than specifically to passkeys, aren't they?

It sounds to me like passkeys are a simpler and more secure approach that apply within the existing context that requires unique complex passwords for every account.

In terms of solving those issues, a 1Password account configured on multiple devices with a secured accessible backup of the emergency toolkit has been a robust solution in my experience

[crote]

Not really. Every single password management tool allows plaintext export, so making a backup or transferring them to a different tool is trivial. You can even make a paper copy if you want to.

Passkeys, not so much. They are opaque blobs which are never supposed to leave the manager.

[megous]

> It sounds to me like passkeys are a simpler and more secure approach that apply within the existing context that requires unique complex passwords for every account.

It does not to me. It requires complicated cryptography/tools. Passwords are just directly usable information that are much easier to reason about and work with. I can ask a question about passwords and I can figure out the answer or soltuion for myself without looking up any standards, implementation details of someone elses software or wading through heaps of marketing bullshit.

Say I just want to temporarily share access to an account with someone? How? I know how with passwords. Give it out, change it later to revoke access.

Say I want to export access to just select few accounts (and not the rest) I'll be needing when doing X away from my devices to limit the possiblility of forced compromise. I know how with passwords.

How does backup and recovery work? Can I do it fully offline without invloving any third parties? Will I need anything other than a piece of paper? I know with passwords without looking anything up.

If it's anything, it's not simple compared to passwords. It may be better in a few aspects (or not) but it certainly is not simpler to think about.

The difference between password manager with unique passwords per account and this complicated crypto-thing seems very miniscule. You're either sharing a shared secret or you're proving a possession of a unique secret key per service.

The only difference is how things need to be handled if the service itself is hacked. If it only stores pubkeys, the user's secret keys can still be used for authentication. The problem with this thinking is that attacker may have swapped user's key on the server with his own, hijacking the account anyway. In any case this doesn't lead to compromise of any other services used by the user.

Also, FIDO2 can be used to force you to have to use a device you don't trully own for authentication, taking away your software freedom. Passwords can't be abused like this.

[stavros]

Most of your comment seems to be "I'd rather stay with an extremely insecure authentication scheme to avoid learning anything new".

[megous]

Yes, valuing simple and thus very robust things that you can have full control over is somehow something that can just have the explanation you've given, and nothing else. :)

[stavros]

Passwords are definitely simple and robust. Unfortunately, they aren't secure, a property we generally want in our authentication methods.

[megous]

> ...unique passwords per account...

[n42]

if you're someone who uses a password manager already, and is generating unique random passwords for every website, the only appreciable difference between a passkey and what you do today is:

- the passkey is never transmitted anywhere when logging in, eliminating the largest attack vectors for stealing passwords

- you can no longer manually type the passkey in on random devices that don't have your password manager on it

it's basically a really really long password you don't know with some added security guarantees.

if you are not already doing this, then it requires adaptation to a world where you do not know your passwords and they are stored in a vault. this does mean ironing out account recovery for the account the vault is associated with. passkeys don't change that, though.

[somehnguy]

> you can no longer manually type the passkey in on random devices that don't have your password manager on it

This answers a question about them that I've been unable to find a clear answer for anywhere. My passwords are all randomly generated and stored in my password manager. It's cumbersome to type them in on some device without my password manager and I don't do it often, but at least I have the option!

I really don't like the idea that my passwords/passkeys are some thing to just be abstracted away to the point that I have no idea where they are or how to access them manually if needed.

[crote]

Not quite.

The biggest difference is that websites seem to trust a passkey as both a password and a 2FA token at the same time. So security-wise it essentially means giving up 2FA altogether, as passkeys are about as secure as a password manager.

So for anyone with a password manager and 2FA tokens, passkeys are a downgrade.

[stavros]

This is wrong. Everyone here confuses "Passkeys the standard" with "some hardware implementation they've heard of".

Yubikeys require a PIN, and the key is wiped if you enter it wrong ten times. Nobody stops you from making a hardware key that requires a long password to access it. You can do whatever you want, the standard doesn't care how you want to secure your keys. The standard just asks for a key at enrollment and then asks you to sign something with that key at signup.

Anything after that is up to you and your choice of device.

EDIT: I've written a short post to clarify a few misconceptions:

https://www.stavros.io/posts/clearing-up-some-passkeys-misco...

[n42]

that'd be more of a choice by the service operator than a design detail of passkeys, right?

[JohnFen]

> you can no longer manually type the passkey in on random devices that don't have your password manager on it

This is a huge problem, though. My password manager has no online component, and only runs on my phone. On purpose.

When I use it, the password manager shows me the password that I need, and I type it in manually.

I could change to a different method, but then I lose a lot of flexibility. I can no longer log into things from machines other than my own.

Things like Yubikey address some of this, but then I can no longer log into machines unless I have sufficient physical access to plug the key in.

To be clear, I'm not arguing that any of this means passkeys aren't desirable, but I am saying this to point out that passkeys are not functionally equivalent to passwords, and passkeys do restrict some kinds of use.

[kdklol]

No, it's not "just a long password". Here are the main benefits not mentioned, which a password cannot offer, regardless of how securely it is stored: - Phishing protection - passkey credential will be uniquely bound to a domain, so you cannot be phished - Keys cannot be exfiltrated from the hardware, so even if your password manager is compromised, your key would still protect you - Duplication protection - synced counters are stored on both the key and the server, so even if somebody does clone your key (very difficult), you'll know about it (unlike passwords)

Obviously, there are some necessary assumptions made, about security of the passkey implementation, DNS security and so on.

>if you are not already doing this, then it requires adaptation What doesn't?

>ironing out account recovery for the account the vault is associated with Agreed. This is currently the weakest point in web security in general.

I'd also like to mention (for everyone else reading this) that a unique set of credentials is generated per account, so this cannot be used to track you. Also, it's an open standard and open imolementations exist. It is bot reliant on google/yubico/"big tech". They're pushing it because it works.

[nottorp]

> Obviously, there are some necessary assumptions made, about security of the passkey implementation, DNS security and so on.

Basically you need to trust more vendors of security solutions than before, isn't it?

Plus you cannot access your accounts from any random device without an intricate security setup that eats at your time and messes with the device.

As in you cannot borrow your friend's laptop for 5 min to check your email any more. You have to set up your keys on said laptop and then remove them, which makes it a 2 hour affair?

[kdklol]

I knew I should've explained myself in more detail. Sorry.

>Basically you need to trust more vendors of security solutions than before

Yes and no. You may have to trust the vendor of your hardware key, or you can get one that has open source firmware, like NitroKey.

Regarding the number of trusted parties - it depends. To have a account that use passwords, you must trust them to handle your password well. You can mitigate this trust need somewhat by using a password manager and strictly using unique passwords (and ideally usernames and emails too!), but this now requires trust in your password manager. Again, OSS solutions like BitWarden, KeePass and pass make this less of an issue. My point is, if you are handleing your passwords well (ie you are using a password manager), you are not really required to trust more parties, only change which ones. Furthermore, WebAuthn is stabdardized, so unlike with password managers, there's less room for "creative" programmers to make mistakes (like lastpass did).

Regarding DNS security,

I meant that highjacking a company's domain, be it trough compromising their account with their registrar or by non-validated or even non-existant DNSSEC can enable attacks. This is true of other forms of identifocatin though. I just want to be fair and not oversell this tech as a silver bullet. If all things are done right however (like they must be with other forms of id.), this does significantly increase security.

>borrow your friend's laptop for 5 min to check your email any more

In general, no. Assuming they run a reasonably recent version of Chrome and Windows/Linux/Android* (I don't have apple so idk), it will work driverlessly.

You may be surprised to know this, but it's fundamentally a fairly old technology at this point. Hardware keys have been supported in some capacity by systems for over 10 years now, and WebAuthn essentially just standardised what was already there. It was a fairly easy adjustment. At this point in time, I don't know of any hardware key being sold that does not support this nor any common OS (again, besides Apple stuff, they should supported but I cannot test it.)

*Ah, yes, Android is a wierd one. Technically it's not yet in android, but it's been in the Google Play services for years now. But thechnically, there are android devices without those (like mine).

[nottorp]

> In general, no. Assuming they run a reasonably recent version of Chrome and Windows/Linux/Android* (I don't have apple so idk), it will work driverlessly.

What will work driverlessly? The generating of new keys that still will take an hour?

Also excuse me, but did you just say Chrome? I should send Google my browsing so I can use passkeys?

Edit: forgot to mention their AI bans with no appeal process. Do you really want your sole login means in there?

[kdklol]

>What will work driverlessly?

WebAuthn. So, registration and authentization. I'm not exactly sure if which standard deals with changing PIN, but it worked everywhere I tried it out of the box.

>OMG did you say CHROME??!!!

Yes, how dare I... It was an example. I don't use Chrome either, but not many people do use other stuff, so that's why I mentioned Chrome specifically.

Currently, the support is best in Chrome and some other Chromium-based browsers. I personally tried Brave, which worked flawlessly everywhere. Firefox (which I personally use) works with standard WebAuthn, but some big players (Google) seem to have older implementations predating the standard, so it doesn't work with some clients (Firefox) yet. I've watched a conference some time ago where they said they're working on it™.

If you want to know how exactly it stuff works, Mozilla has a nice and easy to comprehend description on their developer site. It's one search away (in your preffered search engine).

>The generating of new keys that still will take an hour?

Are you trolling? No. Also, only nonces are generated for each new _credential_, so you don't need to store so much data on the key. You should be more worried about how long it will take to do the authentization exchange, which takes under a second from my experience.

Please just read the Mozilla website.

[tptacek]

You say "even non-existant DNSSEC" here, but, as a reminder: virtually none of the most popular/important/commercial/whatever-ranking-you-like zones on the Internet are signed. DNSSEC signing is not the norm.

[kdklol]

Not quite true, many popular services do have it. Especially the big ones.

The thing is, I was mentioning DNSSEC as a "full disclosure". Any attack enabled by non-validated DNSSEC on passkey applies to any other form of verification too. I just wanted to make sure I'm not overselling the technology, it's not a silver bullet, but it's orders of magnitude better than anything else.

[n42]

I was speaking about the experience of a user who doesn't care about the details :)

[kdklol]

I understand. In that case I still think it's a bit of an understatement to call it a password, since especially inexpirienced users are more vulnerable to phishing, and this does protect against it, unlike a long password (even paired with other MFA methods!) Also there's nothing to remember or to install, so again, more normie-friendly. Sorry if I came of as too agressive, maybe I should've put in some smiley faceses too :)

[warkdarrior]

> How do you recover your keys if you lose your hardware? What happens if you lose your phone and have no extra trusted device?

You get a new device, create new passkeys, and re-enroll into the online service again.

> And, for Yubikey, how do you backup?

See above.

> Do you need multiple Yubikeys?

Yes.

> Do you need to manually make a copy of every keys? How do you know if the copy is synced with the main one?

Apple's and Google's solutions both sync the passkeys via their cloud services. You cannot sync passkeys to Yubikeys, AFAIK.