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 :)
I don’t understand why someone would want to store all their credentials with one of the large tech companies. It seems like this makes it really easy for law enforcement to grab access to all accounts easily.
Passkeys are WebAuthn under the hood; they don't store your credentials with a large company any more than using a hardware token stores your credentials with Yubikey.
Apple does some additional trickery to synchronize credentials between devices, but they get away with this because their devices have contained dedicated silicon for sensitive data management for years[1]. They have some user-facing documentation on how their passkey implementation is synchronized between devices without any secret disclosure here[2][3].
Apple can synchronize the passkey between devices. As far as I understand I cannot. So I don't really understand how this can be said to be a hardware security token. It seems pretty clear that it is as far as I am concerned, but that Apple has nothing constraining them from copying my passkeys. Which seems like the worst of both worlds.
>So I don't really understand how this can be said to be a hardware security token.
No one claimed it's a hardware security token, but the private keys are stored in iCloud Keychain, which is end-to-end encrypted. Apple cannot access your private keys even if iCloud is compromised by an external attacker or employee.
If you're curious about the security engineering, you should watch the "Synchronizing secrets" part of this Black Hat talk from 2016: https://youtu.be/BLGFriOKz6U?t=1353 or you should read the "Synchronization security" section of the "About the security of passkeys" support doc: https://support.apple.com/en-us/HT213305
This is indistinguishable from the "I don't trust my computer" threat model. Apple could also surreptitiously scrape your screen or copy your processes' memory.
It’s not, because law enforcement considers your computer as private property, while anything you upload on the cloud is seizable without warrant. I’m not joking, it was rapported on HN at the time of the Snowden leaks that NSA can legally monitor your data as long as you transmit it over the wire.
If your threat model includes getting hacked by the government, then your only choice of OS would be some hardened open source OS with fully reproducible builds and no proprietary driver blobs installed.
There is no need to mess with the E2E, the client installed on your machine is downloaded form their servers, they can just copy the data when it is decrypted locally.
I does not make sense to use a proprietary internet connected application on your machine and worry that that the servers might be nefarious.
Could you give an example? That support article doesn't mention anything about it. I do recall reading something about that recently, but I read the article and it it made no mention of what syncing passkeys actually means. It sounds like theoretically I could write an app that uses the same APIs Apple uses to sync encrypted credentials between TPMs. But "however you please" sounds suspiciously like "however you please, as long as you don't sync it to anywhere Apple can't vouch for the safety of the keys."
It has been a while since I have dug into it, but from what I remember it works roughly like this:
You login to iCloud which gives your device write access to iCloud storage. The device creates a private key inside the TPM, and uploads the public key. When you add a new device, one of your existing devices has to use its hardware key to sign your new devices key. It also must be signed by a second key derived from your iCloud password (so you). Apple doesn't go into the details on this, but I believe the originating TPM also signs the key with a chain of trust that goes back to Apple itself.
The keychain is encrypted locally and exported to iCloud. The key used to encrypt the keychain is also encrypted using the public keys of all trusted device keys in iCloud that have both a signature from another trusted device and from you.
As a user you can also just open up Keychain Access on a Mac and ask it to generate a CSV export of your entire iCloud keychain - which is how you would go about migrating to another password manager.
I'm sure that works for passwords. I am skeptical that it works with passkeys. It's unclear to me if the CSV will include passkeys. It's additionally unclear to me if I enroll in some website with a passkey stored in my Keychain, and then export and import that password into some other password manager, if the website will accept a login from the exported passkey. Definitely, there's the "attestation" piece and services might choose not to accept the passkey if the attestation has changed. You can blame the service - but it seems like an intentional design goal here. And it has been said that Apple didn't want attestation, maybe it will be removed, but it's there and it seems likely to be used.
Except that passkeys are treated as both a password and token at the same time. They are the sole thing needed to access a website, so you are absolutely storing your credentials with a large tech company.
When you use passkeys with either Apple's iCloud Keychain or Google Password Manager, the key material is end-to-end encrypted. Law enforcement cannot get your passkeys through these two big tech companies.
This is a great point. And to respond to the other part of the parent comment about storing "all their credentials with one of the large tech companies" — you don’t even need to do that, if you don’t want to.
Apple just extended their Credential Provider API such that passkeys can now be synced using external providers, meaning password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. So you can choose to sync your passkeys with whatever your favorite password manager is.
Yes you need to trust your operating system developer to some extent.
If your threat model includes not trusting the company that writes the source code to your OS…don’t use computers I guess?
The concern is not about trust but gatekeeping the providers.
For example in the case of email, you generaly dont worry about google reading your email but we should definitely be concerned if gmail allows send & recieve from only few domains or providers it chooses.
Suppose one does trust their OS developers. And they want to use some passkey-protected service.
Does that service also have to trust the OS developers? Correct me if I'm wrong, but I'm under the impression that services can decide whose passkey implementations to trust.
Seems like that should be up to the user, not the service.
What is it encrypted by? Or asked differently, what does the user need to have to decrypt it on all their devices? And how can we know that Apple & Co. don't also have access to that? It's not like Law enforcement hacks into your connection, they just force the company to hand out your data.
For apple, yes. but as i understand it, your passkeys are not synced or stored in google password manager, they are only stored on device and never synced through or stored on google servers.
Regardless of how much you trust them, the fact that they can force a decryption of these keys (and selectively, per-user, no less) means that you are not in custody of your own authentication identity. Add to that, they can be legally compelled to take such a measure (and I'm sure they will in due time).
Compared to using, say, KeepassXC with a unique, secure password per vault. Now you can sync on iCloud or google drive, but neither Google nor Apple can decrypt the vault; the keepassXC maintainers presumably could make a malicious update (which you'd still have to accept, since the updates aren't forced on you), but that would also affect the security of everyone using KeepassXC (and potentially be much more harmful to the economy and society as a whole than the government is willing to accept in order to get intel on an individual person of interest)
KeepassXC has a ways to go still before I can trust it. I just attempted to use it again, after a few years, and syncing the DB across google drive randomly caused all of my entries to be erased. No recovery, nothing. just opened the DB one day and all of my saved notes and passwords went poof.
It's a know bug, but the fact that it still exists really shows how much the devs care about making it a really rock solid alternative. I've never had this issue with Google passwords, 1password or any other provider.
Oh for sure, KeepassXC has some UI issues. And in this case, a glaring bug, thank you for making me aware of it! It looks like there are workarounds, though I'm not sure how much I like them.
I've already been doing manual backups. In addition, there is a feature to make a copy of the database before writing that I've just turned on. And the "Use alternative saving method -> Directly write to database file (dangerous)" option is supposed to prevent this issue from happening with cloud storage.
I wasn't in any way arguing KeepassXC is a layperson-friendly way to manage authentication credentials, just that it gives you the most security from the big identity providers (Apple, Google) selling you out for political or selfish reasons.
Of course, there's probably only so much I can do here. Apple could presumable ship an update to their OS that allows them to access a user's database while it's unlocked, or to keylog the master password.
A yubikey might be the only thing that can really protect you here.
Remember Snoden. IIRC only two or three guys in all of Skype knew about/worked on the backdoor. Everyone else would have sworn it is end to end encrypted all the time.
When Apple or Google receives a request to give user data, and they get thousands of such requests, they compare the cost of complying and the cost of not complying. I'll tell you an open secret that such companies are doormat-level compliant and are very very proud of that.
I think it depends on your threat model. For my personal accounts, I'm more concerned about the risk from badly-managed auth than law enforcement. So from that standpoint, using an established big tech company makes sense. Other people may place different weights on various threats.
Then we are at passwords again where I can happily exclude both. Convenience might be an advantage, but I don't see me using such an auth solution for my private accounts.
I have an honest question, but am afraid that I get downvoted for reasons that perhaps relate to my question:
Why is this on top of HN?
Is it a novel invention by Tailscale?
Are they the first company who’ve done it?
Are they used by so many people (like GitHub) that this will have other implications?
Does the article go to technical details of their implementation that relates to the dev crowd?
Mainly because Tailscale is popular with the HN crowd. Many people use it for their personal home networks, and some companies do to (we do at Instacart).
The nice thing about this is it means you can invite anyone into your network without requiring them to have a Google/Apple/Github account. They just need a phone. It also means you can be much more confident inviting these people because they are unlikely to get phished due to a crappy password.
One of the common complaints in HN comments about Tailscale is they don't want to trust Google/Apple/Github/etc for various reasons. This removes that need.
People love Tailscale, and passkeys are relatively new, so a major authentication improvement for a well-loved service that is based on a new authentication mechanism not lots of companies support yet is … interesting. I think it’s as simple as that.
I dno; people used to say that about Dropbox in the early days. Clearly people like what Tailscale is doing, and find it interesting. The upvotes are about what’s interesting to the community, so seems fine and not cult-like to me.
It's a product a lot of people use and it is nice to be informed about its development. At least this news entry is not the n-th "here's my top life advice" from a 30 years-old.
I don't really know anything about Tailscale. But I really dislike passwords — I think they're very frustrating for users to use, and it feels like we should have found a technological solution to this problem by now. Passkeys seem to be a solution to this problem, but it's up to people to adopt them. I upvoted this post so that others might see a company implementing passkeys, and that this might encourage them to implement passkeys too. Once we have widespread enough support for passkeys, maybe we might finally ditch passwords.
(Or, maybe passkeys are bad, I don't know, but we need to have a conversation in order to find a better solution.)
There is obviously a big marketing effort from Tailscale going on. It doesn't bother me too much, it's not like they are raw astroturfing and drowning HN, a lot of people are happy and engage with the posts. Personally I don't like it and won't use their products, but it's easy to ignore here.
For those of us wanting non-big-tech implementations of WebAuthn/passkeys, there are options for storing passkeys in software, and for storing passkeys in TPMs.
What the heck? SMS as a second factor was considered bad practice ten years ago. Allowing it to be used as the only factor to access your entire Apple ID is absolute negligence as SIM-swapping is still and forever will be trivial. I'm genuinely shocked. Engineers at Apple must have been screaming into their pillows at night as they watched some incompetent BA ignore all advice and force this through.
It's true - I have to use SMS as second factor to log into iCloud. Apple don't let you use a generic OTP as MFA - the only other option is to get a notification on your iPhone or iPad. I don't have an iPhone and I rarely have my iPad with me, so SMS is the only way I can log in to icloud.com.
My guess is that they aren’t making things less secure. There are flows that let you reset your password but don’t let you login today, so letting you login via those flows would be a step up in usability.
If you don’t have your phone as your second factor or can’t use phone today to reset password, then I don’t expect you’ll be able to login via that mechanism.
Ah yeah that’s true, it’s no less secure than recovery via phone number.
Not entirely sure how to prevent recovery using a phone number. I wonder if this means setting up a recovery key instead? Been considering doing this anyway.
My work uses Microsoft SSO for everything. Passkeys aren't enabled though. And management won't enable them on Azure AD. Instead, they enable the tried and tested and ultra secure method of SMS based 2FA with a password. (This is sarcasm.) The alternative is the Microsoft authenticator app with its associated risk of approval fatigue. I have already had several malicious login attempts. Fortunately I'm attuned enough to decline them.
The only way I'll get passkey logins for my work account is if Microsoft force it as a 2FA method for enterprise. I won't hold my breath.
The last time I used Microsoft Authenticator (which was quite a few years ago), I noticed it would send me a request regardless of whether the correct password was entered or not. I suppose this is one of those "security by obscurity" type measures where they don't want to reveal whether the password was correct or not before MFAing. However, this results in non-stop requests because every few hours someone somewhere in the world attempts to penetrate my MS account.
This became so tiresome that I disabled MFA. Here's a hot take: if your MFA solution fatigues people to the point they disable MFA, you have a problem.
Also, I'm wondering if the OP might be referring to passwordless "Approve this login request" notifications rather than plain old MFA, where someone just needs to enter your email address and hope you approve the login request. Not sure if MS does this, but I know other apps that do.
I assume this is referring to the passwordless logon feature, which most enterprises disable. But with this feature, you just need to enter the username (email address) and choose the option to log in with authenticator.
Regarding MFA-fatigue, this is mitigated by asking the user to enter the same number into Authenticator that is displayed on the login screen. So that takes away the chance of accidentally approving an MFA prompt.
I assume this is referring to the passwordless logon feature, which most enterprises disable. But with this feature, you just need to enter the username (email address) and choose the option to log in with authenticator.
Since they talked about the authenticator app, it depends on how it's set up. You can enable it for passwordless logins, so you'd get the prompt for knowing the account name.
> My work uses Microsoft SSO for everything. Passkeys aren't enabled though. And management won't enable them on Azure AD.
I don't think they're actually available on AzureAD. That thing tends to lag like crazy in actual security features. FIDO support is relatively newish. IIRC it was generally available around the end of 2022. Only recently, you no longer have to register a phone number for password reset (which is different from login, mind (SSPR)).
> they enable the tried and tested and ultra secure method of SMS based 2FA with a password
This isn't actually that much worse than the MS recommended way of using their crappy authenticator. They even allow passwordless sign-in with that thing! The prompt doesn't tell you anything useful apart from "login with <account>?". Now, at least, they prompt you for a number you see on screen. It doesn't help with phishing, but at least you know the request comes from what you're doing, not someone else, since it also tended to drop any request if another one was pending.
My employer uses the MS Auth app. Now when logging in, it shows a number on the screen that you have to type on the app and then use the finger print. Before it used to be the fingerprint only. Seems like a relatively effective way to ensure people are not just approving everything prompted by the app.
Does anyone know what's the intention in doing this? The default behavior of OTP was afaik always to generate a code on the second device, and input that into the device you are trying to log in with.
I assume Microsoft felt the need to dumb this down so it's easier to just approve it with a click of a button, then after they realized this is bad (that pretty much anyone with a bit of security experience predicted) they now changed this to "input code on second device", instead of just reverting to the default behavior.
All of these are options that your company chooses from. It's possible to have it just show an approve button, to have it show a selection of 3 numbers, or to show the number entry box. Whether or not you are prompted for your password on the device you're logging into is also a decision that your company makes.
Authenticator has options that avoid approval fatigue. There's a setting that causes it to show a number on screen, and then an option between providing a list of 3 numbers you have to pick from or showing a textbox that you have to type the displayed number into. If it's set up for textbox entry it's unlikely that someone is going to approve a random request.
Ok Tailscale. You like to get on the latest security buzzword bandwagon, very nice but this makes me trust you less.
Passwords are outdated in the same way key locks ok doors are outdated and all they did is have someone else manage federated authentication.
I am so exhausted at screaming into the void over this topic. You all do whatever crap you want just know that whatever you do, if it isn't at least 2FA it is as shitty as passwords. New and secure just means threar actors haven't adopted to it yet. You know the nice thing about old shitty security? There is decades of work and lessons learned on how to make it work nice.
Keep your silverbulletd and reinvented wheels and give me knowledge based factor (password,passphrase,pattern,etc...) and a completley separate NGC like FIDO2 and credential recovery options that don't involve email or yet another set of credentials. Now, that hard security implementation will actually keep me secure but these lazy bullshit security anti-patterns force me to depend on some bullshit 3rd party vendor, compromise on my privacy and still have me be one step away from total pwnage.
All tailscale has convinced me is that they think passing the buck to someone else or getting in on a hype is in the best interest of their users as opposed to investing in layered and reliable security.
Probably a bit early to rely on this exclusively; for example Firefox support is not there yet (only works if you have ubikey). Apparently they are planning something there. Bitwarden recenly announced that they are implementing support; and there are probably a few others that are going to do stuff in this space.
I do see the appeal for passkeys but I think short term it's probably going to be a support nightmare. The messaging around this is also quite confusing for example. Way too technical to explain to normal users what this even is or how it works and what they need to do.
Also, as others have pointed out, while this is more secure than relying on passwords (given users can't be relied upon to follow most of the sane recommendations for these), it doesn't remove the need for multi factor authentication. A lot of passkey implementations basically rely on some variation of biometrics. Those aren't exactly hacker proof. And of course phones get stolen and lost all the time. Which creates the need for some recovery mechanism as well as a way to revoke passkeys.
Like many round trips we have made, I suspect in the year 2035, we’ll look back and say to ourselves: “Yeah, password was super based. Just copy paste it in the box and you’re logged in. Can store it anywhere, even in a notebook. Safekeep it by printing them. No need for HyperBigTechCorp. Portable. Those gray beards had it right the whole time.”
Can we please stop the bandwagon for a moment and inquire about the downsides of Passkey?
Technologically there's nothing really bad about them (imagine a managed version of ssh keypairs). Technically they could even be backed by physical devices like Yubikeys and never touch the cloud.
My worry is the actual implementation, where platforms might lock you into their cloud as the sole provider simply by not implementing interoperability...
How do you bootstrap it? You get robbed at gunpoint by some ruffians and they take your wallet, cellphone, keys, and laptop. Hopefully they can't get into your accounts, but never mind that, how do you get back in to everything?
> generate a special bootstrap key you can print and save
So ... a password?
Also in this scenario you've been robbed. It's quite possible that either they took your printed out passkey also since it was in your wallet, or you're not at home where you can get the pass key from your file cabinet or safe.
Not really. A password is meant to be memorized and reproduced correctly regularlt, whereas a recovery key doesn't need that and can be very long and complicated since it is rarely used.
The comments are full of statements regarding security capabilities for passkeys. But there is no public specification that even defines requirements for the exchange of passkeys between devices. Google and Apple make statements on their websites regarding the security, but all of it is practically unverifiable. Please note that end-to-end encryption is useless, if you are not controlling all the endpoints.
Sites of course could use the device public key extension of the WebAuthn protocol, to rely on more than a private key copied intransparently between devices, but I wonder, who will even know about it and actually use it. Google has stated they support the extension, but I cannot find a statement by Apple. A question whether DevPubKey is supported by Apple is unanswered on the Apple Developer Forums.
It is telling to me that the passkey spec has provisions for attestation which will allow lock-in by providers and lock-out by websites based on your provider, but questions of backup, account restore and interoperability between providers receive some hand-wavy "the market will figure it out" response.
Good. I get they don't want to be responsible for keeping user credentials. But requiring permission from a big tech company to manage or access your own networks boggles my mind and made me not use it.
Now if only they supported this for setting up the entire account too, as opposed to additional users only. I hope that's coming.
Yeah absolutely - I think this is a relatively recent change for them. The only thing stopping me from doing that is that 1) setting up an OIDC server for personal use is a lot of work I don't necessarily want to do, especially if it's just for Tailscale 2) this announcement suggests they may be working a full passkey setup, which would make that work useless.
It installed flawlessly on all of my machines (Linux and Mac), and now I can route to all of them wherever I am. It configures DNS correctly, it routes traffic correctly, and all of my internal machines at my house are routable when I'm out in a coffee shop or library or hotels. It's been more than a year and it's operated flawlessly, never needing maintenance or restarting, it survives connection resets and is completly robust. I just love it.
Disclaimer: No affiliation other than being a happy customer.
I wanted this to be true for me, but on Android it sometimes kills my internet connection (even when turned off) until I force-close it, on Windows it'll hang and consume lots of CPU every few days and on Linux (Ubuntu/Pop) the service sometimes stops and I don't know why. I just have bad luck, I guess.
(On-topic, I would prefer them to to take my damn password please.)
Is there a good plug-and-play Java framework for supporting logins via identity providers like this (including passkeys) for web apps? As I build out a web application, I would like to avoid having to do all the hard work of implementing this if I can just grab a jar and have it done for me.
Modern password managers run into issues regularly that still require a user to copy/paste a password out of a secure location. I don't know what the solution is for these situations with passkeys, but I know I don't trust password managers to do it right.
I've used iCloud, Google Chrome, Lastpass, and 1password, and they all break consistently in a few scenarios. Three that come to mind are:
- SSO or other systems where multiple logins are linked to the same account on different host names. The password manager will require you to essentially create a separate entry for the new site that becomes disconnected from the original.
- Having multiple logins for the same site. This breaks especially with services that use a multi-stage login, but in general it breaks frequently. If you have kids or parents whose accounts you manage, password managers will invariably ask to update the wrong password, or attempt to auto-fill the wrong password regularly.
- Sites that request you enter the old password at the same time as you enter your new password for verification when changing a password. Password managers can't figure this out, and as a result whenever I have a password manager generate a new credential, I also make sure to copy it to a temporary location until I've verified that it was saved. Typically, because you entered the old password on the password change page, that save doesn't go through.
In the end, all these security features just boil down to how secure your password reset/customer support function is. If you're going to require people to reset their passkey every time they log into your site, why not just use a "magic link" email session initiator and be done with it?
I don’t know, I’ve found quite a few work arounds for stuff like this with BitWarden where the experience is pretty seamless and I routinely deal with all of these issues except SSO.
BitWarden has its problems but generally I find the experience pretty good - indeed far superior to the other services you mentioned. The ability to use “secure notes” and the convenient way that has been implemented in BW has allowed me to be fine in all the scenarios you’re mentioning.
Of course, you’re right, you still have to copy the password in somewhere, but ultimately I feel like that’s a lower threat if properly handled than what I used to do (shitty insecure passwords).
The other thing is I barely ever use the browser extension for the password manager. All of the browser extensions I’ve tried other than BitWarden have been janky and even that’s only ok. Still, try BW I like it way better than lastpass and 1password.
Not really, the technology behind passkeys behave kind of like managed ssh keypairs.
While they can be designed to have the secrets cloud synced (just lile how you can sync your ssh private keys), there's nothing preventing them from being implemented in other ways, like having them backed by a third party password manager or even a pyhsical token like a yubikey.
Of course, this depends on the software (OS, browsers) actually respecting and supporting that interoperability. But that's not really a limitation of the underlying tech.
Is there a way to store the ultimate root of trust somewhere non-digital? I currently have my most important root-of-trust passwords printed out on paper stored in places I consider long-term secure. At least in my personal physical and social context, I don't trust any cloud account or dongle to a similar extent.
I'm still sceptical of passkeys. Either there needs to be an easy way to generate multiple ones, e.g. having multiple devices that can login. Or it should be easy to export and import them. I don't want to my account to be bound to exactly one specific device of mine... or to need to rely on some cloud sync provider (like Apple or so).
I personally think having a browser-managed "private key" (the same kind used for ssh auth) would be better, but now as a user you have to manage the multiple private keys you have associated with an account; a totally confusing concept for the average user.
I haven't yet looked into the inner mechanics of passkeys, and the link only talks about the first login. What is the experience like when a user wants to log in from a different system? They press the "Login with Passkey" button on Device 2, and then...?
Note that this requires a "nearby device", which is determined via Bluetooth. There are lots of desktop PCs without Bluetooth, so this requirement is kind of a serious problem.
Google is trying to tie the Google account to a single device at the moment. Just yesterday, signing to a work account requires 2FA (enforced by the organization) and then click a number on Gmail app.
> Passkeys are synchronized across devices using services you already use and trust, like iCloud Keychain from Apple, Google Password Manager, and 1Password.
I don’t trust any of those, and it’s weird that anyone does.
Are people still happy about Tailscale being a user land version of wireguard? The last benchmarks I saw showed an ~ 50% performance penalty over the native kernel level implementation.
Plenty of use cases where performance doesn't really matter, and getting it working is orders of magnitude easier than wireguard. I've been using it for about a year now, and I rarely notice it even exists.
There's no "passkeys" protocol. If there is, it's well hidden behind marketing bullshit. :)
> In marketing material, the terms passkey or Passkeys are preferred over related terms such as FIDO or WebAuthn, because they are less likely to cause confusion.
Yeah. Nowhere does it say what it actually is or how it's related to the other standards. Not confusing at all.
Yeah it seems sort of like web notifications and I find it quite centralized, favoring the browser vendor. So I'll have to see what it's like in practice. But I hope it doesn't take off.
How so? Apple's already announced support for 3rd party passkey stores to integrate into the OS (to allow passkey authentication in apps), and the 1Password extension supports passkeys across the major browsers (though support's in beta).
I'm pretty sure passkeys are just a rebranded version of virtual WebauthN tokens.
So while passkey secrets can be synced (unlike U2F physical tokens) they can also be implemented as being backed by a physical token (think Yubikey) that never goes om the cloud.
... Unless you care about that and use a Yubikey or other physical security key.
There is absolutely nothing stopping you from doing so as long as your Yubikey supports WebAuthN (the latest do). You are prompted to use another phone or physical security key if a resident key isn't found on your device, and even if it is, you are given the option of doing so instead of using the one found.
This is not a hypothetical feature or theory or something, it's part of the spec and is implemented. It's as practical as it gets.
"Passkeys allow you to go passwordless — rather than a password that can still be phished — you get strong credential that syncs securely across your devices, using your chosen password/passkey manager."
This sentence doesn't quite make grammatical sense to me. Is there a typo or two here, or am I missing something?
Ah, thanks, I think it makes sense now. The use of hyphens is confusing too. I would have preferred either:
> Passkeys allow you to go passwordless: rather than a password that can still be phished, you get a strong credential that syncs securely across your devices, using your chosen password/passkey manager.
OR
> Passkeys allow you to go passwordless — rather than a password that can still be phished, you get a strong credential that syncs securely across your devices, using your chosen password/passkey manager.
