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?
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.)
>>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.
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.
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.
Well, I disagree. People aren't saying "I want to use this today and can't because X is missing", they're saying "I'm opposed to this technology because X will never be possible", when it will be.
Look at this comment, as the first example I found:
It basically says "Passkeys = USB keys", which is wrong. If you don't like the tradeoffs that specific authenticator makes, use another passkey authenticator type.
"Passkeys are strictly less secure" is just objectively wrong.
I don't think it is different. I mostly see people dismissing Passkeys as a technology because of X or Y thing that "they don't do", when that's either a mistaken assumption, or something they don't do right now.
Mistaken assumptions, sure. What "mostly" people do maybe, it depends on those conversations. What Passkeys might do in the future is irrelevant to whether it makes sense for people to be dismissing them now, though, and confusing/frustrating to read about in these kinds of threads (maybe not other threads).
Today, you can seamlessly sync your passwords, export them, and utilize auto-fill integration across the aforementioned devices. Not "it could be possible based on the design if the manufacturers and apps wanted to do it", it is possible.
Today, it is not possible to do the same on those devices using Passkeys. That's not the same as claiming "it's guaranteed to forever be impossible because of the inherent design of Passkeys" and reading every conversation as such could well be the source of why the misconceptions seem so common. There is little to no guarantee from any of these manufacturers it will ever be possible either, so predicating the conclusion on that possibility of change definitely occuring isn't sensible. Again, not because the Passkey spec can't, the devices/implementations may just not want to. Remember, the spec doesn't require devices and implementations allow it to happen, it just accommodates for the possibility.
If implementations available for people to actually use change in the future, so will the dismissals. In the meantime, the dismissals of what's not possible are not misconceptions just because it's possible it may change down the line. It still remains impossible right now, even though I'm hopeful it will become possible in the future.
And again, sure - other threads probably have a lot of flat mistakes or different claims. But, if I wanted to discuss what other threads are saying, I wouldn't be reading and replying in this one.
Thank you for eloquently putting this. I am exactly in that boat. I'm reasonably IT savvy but not a security researcher. I help a large number of not tech savvy people with advice.
I don't care to either dismiss or evangelize the technology based on what it may or may not be able to do in the future. My questions are whether these are user friendly and usable today or should I wait and see. I feel all my concerns of "if I and my family adopt this right now, today, on my actual devices, what are my risks and capabilities? How can I safety my family and backup things and set them up for success?" Are answered with "in the future, in theory, somebody somewhere will come up with this solution which is not currently strictly prohibited "
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.
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.
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.
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.
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.
> It shouldn't be this hard to figure out the basics
Why not? There are lots of great things in the world that are easy and a joy to use, but fairly challenging to learn the technical details of. The electricity grid, airplanes, microwave ovens, you name it. Tons of straightforward user experiences that take some work to understand.
I don't see people having trouble grasping the technical specifics, I see a lot of people having knee-jerk reactions and reacting to their own assumptions of how Passkeys work.
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.
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.
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??
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.
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.
> 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):
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.
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
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.
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).
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).
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.
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.
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.
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.
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?
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.
> (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.
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.
> 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.
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.
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…
> 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:
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.)
> 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.
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.
FreeOTP is another alternative - passphrase-encrypted backups can be saved to local or cloud storage and imported to FreeOTP running on another device.
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.
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.
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?
> 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.
> 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.
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).
Again, though, that's beside the point. If you want a system that provides that, use one. You aren't locked in to any single company. It's an open standard.
Again. No system that I know about provides those properties today, so your "use one" advice is, unfortunately, impossible at the moment. Well, without having that rite I've already mentioned a few times (which violates the "convenience" property).
It's an open standard that everyone are building siloed systems on. It's exactly as you have said - I'm not locked in to any single company, but if I have devices or programs from multiple companies that bundle different implementations and don't let others in, I don't have any means to make them interoperate.
This could change someday. Fortunately, there is no fundamental design issue that prevents it. But I'm talking about what exists today and how the standard is bad for not even trying to address it, despite this being a very obvious issue.
I don't think that's the case. Yes, you'll have to wait a little while, but it's not like many sites support this today anyway. Very soon, most password managers will support it (KeePass does today, AFAIK), and then you can use your password manager as your Passkeys provider on all your devices.
And even if they will, they're at mercy of e.g. Apple letting anyone to replace iCloud Keychain with a third-party password manager. Which is also not possible yet. Probably the same for Android, although I'm not sure what's the situation there today. (But whatever it is, I would say that "well, don't use Apple/Google devices" is not an option for many in the current duopoly.)
All this can be solved, but the issue that is is not - today. So, today, I'm voicing my discontent.
> and then you can use your password manager as your Passkeys provider on all your devices
In an ideal world - yes. Sadly, I can't do this today with passwords, even though the world had spend many decades on trying to make things as seamless as possible. Over last year I've had to manually open a password manager on one device and type a password on another more than a few times.
The most obvious example is logging in to a streaming service on a smart TV - one step away from the normal conditions (scan-QR-code-on-my-phone flow not working) and typing password is the only option. Netflix is gonna love passkeys so users will possibly have slightly harder time logging in on others' devices ;-) BTW, sharing passkeys is also not exactly a solved issue - yet (even though some vendors made some promises).
Then, there's a case of accessing from untrusted devices (say, a net cafe). Theoretically, Passkeys should be a drastically superior solution to passwords - I would be able to plug in a security key, and it won't leak the keys, so even if a machine has a keylogger or network sniffer I'm still fine. In practice, however, enrolling a physical security key (Yubikey, Nitrokey, Solo) requires having it physically available, so it's always going to be inconvenient - and this is not changing until the standard extends or changes. Worse for multiple keys (I have four so every Webauthn sign-up is a pain in the ass). Because I'm most certainly not installing my password^W passkey manager on some untrusted machine.
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.
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.
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.
Companies aren't willing to lose customers at scale, but they aren't doing anything for the customers if they won't lose them anyway. For most services, most customers except for some diehard ideologists would just bend over and begrudgingly go with the attested option. And a company won't bother using engineer's time if it's only a few people.
So minimum-value random internet blog is probably not going to require attestation - except if they have no idea about it whatsoever and will just use some off-the-shelf solution and enable it because it sounds more secure, without realizing the issue. Anything that has significant value will do as they please and customers may voice some unhappiness, but will obey. And as long as voiced unhappiness is minor (there are always other issues) it will be ignored as not something worth spending resources on (even understanding the issue requires some valuable time).
The issue, though, is attestation doesn't really do much for the site either. It's not like the bank wants to enable attestation because it's somehow more secure. It's only useful in cases where a company wants to say "we only want you to use Yubikeys because that's what HR has approved", not so much for sites mandating what their customers should use.
This is a bit like worrying that sites will block 1password and only allow LastPass. Why would they, even if they could?
Because people are not always rational? Or because non-technical people (and technical people too, just less often) don't always make good technical decisions?
I can totally imagine a case where non-techie Joe starts a small shop, wants a website, sees an ad for a cheap hosting for non-techies, one-click installs Wordpress, goes to settings and ticks the checkboxes because "require secure devices" sounds secure. Or some other reason - people do weird things all the time, I can't count how many times I've looked at someone's server or website (including my own, especially after some time passes) and wondered why something is weird or plain wrong.
You're probably right, though. Attestation is very unlikely to be an issue, if Passkey implementations that don't have it will be popular enough to matter soon enough. And given that 1Password is spearheading it and Apple doesn't have it either - this is probably going to be true.
Attestation could become a real issue only if vast majority of available implementations by the time sites will start to adopt Passkeys will all provide it. Then site owners could make those mistakes and not even realize them. But that's not what seems to be happening so I'm sure attestation won't be a big deal.
Attestation can be more detailed than just what brand of hardware key you use. Banks probably don't care.
But attestation also informs what the capabilities are. What banks (or others) might care about is whether or not you're using a TPM or equivalent to store your key in, and attestation can tell them that.
Fortunately, it seems that major providers don't support attestation. If no one provides attestation capabilities, no one would request it, not even someone as anti-user as a bank.
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.
> 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
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.
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.
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
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.
No Webauthn support at Amazon.com whatsoever. It's mandatory SMS (you must provide a number and you can't say "I don't want this to be even a backup option") with optional TOTP.
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.
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!
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
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.
> 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.
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. :)
Physically impossible to just take someone's HW token. And firmware/HW has no bugs, so malware taking the keys is also impossible to write. There were never ever any FIDO token vulnerabilities and never will be.
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.
> 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.
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.
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:
> 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.
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.
> 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?
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).
> 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?
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.
> 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.
I'm not talking about the CPU time needed to generate the bits...
Aren't the keys device specific so you need to generate new keys on a new device? It's being touted as a security feature. I'm guesstimating that at 1 hour of the user clicking through various interfaces.
But anyway, my concern is passkeys are adding too many dependencies on devices/providers. Giving me a list of possible devices/providers does not address my concern.
The keys are authenticator device specific. So if you put it on your keychain you never need to generate anything to check your email on random computers. If you use a software solution, then you need to sync the vault in some way, and again don't need to generate anything here.
If you're worried about making a brand new passkey because you're logging in from scratch, that means you need some other kind of authentication to start the process. And that's solidly outside the scope of passkeys, so it's hard to say how difficult it would be. (But if you have an alternate login method, a good system wouldn't force you to make a temporary passkey, it would just let you check your email and log out.) (Also it shouldn't take more than a minute to do key creation/deletion in any reasonable implementation.)
>Aren't the keys device specific so you need to generate new keys on a new device? It's being touted as a security feature
Yes, the keys are device specific. This is a feature and the reason why it's more secure. If it could be backed up (exfiltrated), it would not protect you in case your device is compromised, which is one of the design goals. You could probably work around this by using an emulated key (which is what Apple does I think?), but that would obviously eliminate this key security feature.
> I'm guesstimating that at 1 hour of the user clicking through various interfaces.
I see, sorry, I missunderstood.
Again, it's just like changing a password or a TOTP secret. Unfortunatelly, no standard can fix bad UX design, but I sympathize. Silver lining is that even cheaper hardware keys are built like a tank, and software is... well... software.
> my concern is passkeys are adding too many dependencies on devices/providers.
Which is reasonable. The question is, is the dependency worth the security benefit? It seems many major device makers/service providers think so.
> Giving me a list of possible devices/providers does not address my concern.
Well, I can't do anything about that, can I? Nor can anyone else.
I think this is, again, a question of priority.
TLS is now essentially a dependency for using the web at large, but it wasn't in the 90s. I'm sure that is of concearn to some people, but most agree it's a net benefit.
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.
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.
Name the popular services that have it. Here's a start: collect a list of popular domain names --- any of them will do --- and write a bash script that loops `dig ds $domainname +short` over all of them. You'll find that I'm not exaggerating, and that my summary of the state of play was in fact accurate.
There is no value to DNSSEC, which is why virtually nobody seriously uses it.
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 :)
