I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not integrate well with password less so it’s best to stay where I am until things settle out better.
People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-)
Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password.
By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. They provide no way for you to copy and paste the passkey into a website, as you can with a password; there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy.
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login to a website, but the website has no way of knowing/proving whether that happened; they just get the password.
You reset your passkey the same way you reset your password, because passkeys are just passwords that have to be managed with a password manager. Some sites make it easy to reset your password, some make it hard. You know the drill; there's nothing new or different there.
If you're happy with your password manager, there's no real need to switch, but even very "sophisticated" password users have been known to fall prey to social-engineered phishing attacks.
Are you sure you're never going to copy-and-paste your password into the wrong hands? I don't trust myself that much.
Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. I think all the password managers kinda like that, and there's something good and bad about it.
I'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run.
I think that's what you're getting at in paragraph 3?
There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.
It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
> The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
That's simply false, and there are passkey managers that allow this - KeePassXC for example.
Perhaps this is something I shouldn't be feeling, but this bothers me and I do not know why.
I can see that you might not want it exposed to the user to prevent social engineering but at the same time, if I can't view then I don't feel like I actually own it. Is there a mechanism that might exist to help me not feel this way? I am totally new to passkeys as a concept as well, but I understand the larger goal.
Personally it bothers me, and I don't want to feel any different. If I can't back it up or share it, it's not something I want to use. It's different than something like TOTP where even though I can't functionally hand-calculate it, I can still move the secret anywhere I want
When it comes to Apple, or Google, remember that people keep their accounts (and therefore access to their keys) at Apple or Google’s pleasure; people’s lives can and do get upended when Google decides you’ve done “The Bad” and they revoke your account-and there’s no learning what you did. For your, and everyone else’s, security of course.
The desire for better metadata is good, because you don’t want to hand your password for microsoft.com to microsolt.com when you’re in a hurry and a sophisticated phishing email arrived. Still, as an example, I’m trusting 1Password less and less. They just helped me autofill credentials somewhere they shouldn’t have (thankfully to no ill effect) when the password was correctly set up with website information, basically where something was site1.example.com instead of othersite.example.com. Because they ignored the subdomain.
Their response from support? “By default 1Password doesn’t take into account subdomains when suggesting an item…” and if you’re using their desktop product, there you can go change - per-item (wtf?) - whether it requires exact domain match to fill.
As so many other people here are saying, it feels like a mass lock-in attempt. If it’s not FIDO is doing a really good job making it look that way, especially with “attestation” (which could just be Web Integrity 2.0 if misused).
It feels ... suspicious ... to me that in 2024, we're designing a new authentication scheme explicitly around resident keys, but challenge-response is optional. Credentials in any new protocol should never be sent over the wire, period.
> It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
Do you have a source for this? After reading the W3 spec[0] this seems entirely antithetical to the Passkey model and additionally raises concerns about the integrity of hardware mfa devices.
> Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager.
This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is absolutely insane to hand over all your passwords to a company like this.
I have been using passkeys for a while in the form of yubikeys
Best practice is to register two keys to every website. Keep one physically in a safe.
With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.
There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular
Yubikey are $50 so if you are already investing real money in your online security it’s not a stretch to expect that people will spend extra time and money to keep a physical backup
I don’t bother with a safe. I have one key that never leaves my home desk and another I have on my keychain. It’s trivial to register the second key when I am home.
Yes it is less convenient than a digital passkey but there is absolutely no way for a remote attacker to compromise it
> By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain.
There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't show up as a password because the associated URL is mismatched on the mobile app. Like mybank.com and auth.mybankmobileapi.com
1password has a URL field. All you have to do it add the extra URLs
Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site
Except they ignore subdomains. Unless you fix that on a per-item basis, in their desktop application.
I think, finally, that the reason this feels so dirty-apart from companies and lock-in and all-is that it’s taking the “something you know” as one auth factor and turning it into something that, not only do you not know, the big goal of is to make sure you can’t know but something you have.
I have been using 1Password for over 15 years and it has the ability to only show/fill passwords when on the correct site. The issue is, over time, companies shift their strategies on the web. URLs change, while the accounts stay the same. I have had to update these details many times. I've also run into situations where the browser plugin isn't functioning, for whatever reason, and the only way in is to copy/paste. There are also times where I'm not on my computer. For example, I usually piggyback on my dad's copy of TurboTax each year. When I'm over there, I will often need to pull up a password on my phone and type it into TurboTax as it logs into my bank to download the tax forms. Passkeys don't sound like they can solve that problem. I'd question if the Passkeys would work in TurboTax even if I was running it on my own computer.
With passwords and logins, it seems like there are far too many edge cases to draw a hard line to say they are locked in the password manager forever. Having a way to copy it out, or export, is also a way to ensure portability, if the password manager being used ever becomes bad and a different option is needed.
Password managers put users in a vulnerable position, as once a user is invested, they've got you by the short hairs. The thing that keeps this from being a big problem, is that there is always a way out. Eliminating this way out, or raising the barrier to exit, can temp these password managers to extort their users, which is not good.
This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.
You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.
It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.
It's not a problem of mental model, it's a problem of scale. If I'm switching phone, the last thing I want to do is to go to every website I have an account on and essentially do a second sign up. This is simply a non-starter, and is a big part of why companies like Apple and Google are pushing for this spec: it nicely ties you in to their ecosystem and gives you a huge reason not to move to a different ecosystem.
I use selfhosted vaultwarden [0] instance (its a rust implementation of the bitwarden server), and the bitwarden apps (i point the apps to use my server instead of bitwarden).
Vaultwarden + bitwarden client apps (for desktop/browsers) have passkey support, and i've been using them for a month or two without any issues.
That being said, bitwarden client apps for android and ios are going through a rewrite (from xamarin to native iirc), and are yet to support passkeys. However, the bitwarden folk said passkeys are the next feature coming to these apps.
Bitwarden, which you can self-host (I do this) seems to have at least partial support now, and I know they're working on improving it. However, I'm not sure if their client and server are both fully FOSS.
... with some of the functionality of SSH keys removed, like being able to use one key for many accounts, or many keys (on many machines) all for the same account.
>But not the second: on Github for example you can have multiple passkeys for the same account.
People mention the "only a single passkey instead of multiple passkeys" issue because they run into some websites such as PayPal that only let you add one passkey. E.g. :
Unless I'm missing something these are nothing like SSH keys. They would be closer to regular password auth with SSH where you store the password in a file that's only readable by SSH.
SSH keys are asymmetric such that I can make a public half available publicly and then use that to generate signatures of any challenge the server sends.
With passkeys either the server needs to store the value raw(making it susceptible to data breaches or malicious actors), or store the hashed value(making it impossible to do a challenge-response, and making it susceptible to MITM/replay attacks).
It seems to be all the downsides of SSH keys(aka losing it having implications), with none of the upsides, plus additional downsides(hardware devices can only generate 25 unique ones instead of using 1 and sending the public to all services with confidence it hasn't exposed any private info).
> there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy
This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engineered into giving up my long random password than that I'll suffer data loss.
Good for you; I'm ashamed to say that I've hurt my data sanctity far more than any criminal has, with 2am tinkering with my systems.
I have vaultwarden at home but I don't use it because I just know I'll fuck up my tunnel while I'm travelling or something.
This is my threat model: "hi mum. I need you to drive to my house and fish a keyboard out of the cupboard. Plug it into the big black box and type exactly what I tell you..."
I feel like most of the replies to your comment talk about the technical aspect of it.
What’s stopping me is that I don’t have a mental model of the management of the passkeys for the whole lifecycle of my account. Can I use it cross platform? Can I allow someone else to use the same account? What happens if I lose or don’t have access to my phone or laptop? What if I die, can my spouse log in my accounts?
With username/password, it’s very clear what I need. I could write it on paper and give it to someone and it’d work. I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle.
> I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle.
It's my understanding that you can't switch password managers without generating a new passkey for each individual service you use (I'm not an expert here, so someone feel free to correct me). That's already enough for me to not switch.
This is why, for me, the problem is not the passkey model per se as much as it is the inability to export/backup/convert my iCloud Keychain database to another account or platform. Apple could arbitrarily delete my data or lock me out of my own account. Or it could just randomly break with no solution besides deleting the database and starting fresh. And according to the author, this has already been occurring!
>Externally there are other issues. Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.
> I’ve avoided passkeys so far because I just don’t have a good mental model of them.
OK, so the simplest way to understand is to first know about the previous generation.
U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes.
In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compromised machine. You get a separate public/private key pair for every account and website (so it can't be used to track you between websites) and that key pair can be used to authenticate with the website. A physical button has to be pressed to authenticate, keeping it secure even if an attacker has control over your keyboard and mouse. The browser integration takes care of letting the USB key know which website is asking to authenticate. U2F keys have to be used alongside a username and password.
For a variety of reasons U2F keys never really took off. Partly cost, partly the 'what if I lose it' issue, partly lack of uptake by websites, partly difficulty using them on mobile, partly competition from 'log in with google' type systems.
So the trade group behind U2F said "Hey, maybe we could just emulate the hardware secure element in the smartphone's OS? And while we're at it, we could save the username, and use fingerprint/faceid instead of a password, eliminate that tedious button press, and automatically back up the public/private keypairs to the cloud". They kept a USB option about for the sake of tradition, but it's on life support.
So that's the mental model of a Passkey: It's like an impossible-to-clone USB hardware secure element that does challenge-response authentication to websites. Except it's emulated in OS software, and is no longer impossible to clone.
Another way of thinking of it is: It's very similar to using the 'Log in with Google' / 'Log in with Apple ID' buttons you see on many websites, you're authenticating to a service by proving you have access to a cloud account. The implementation details in the background are very different, but the result is broadly the same.
> "and use fingerprint/faceid instead of a password"
This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now?
Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
The fingerprint/faceid is just a local proof to unlock the actual asymmetric encryption key. It is not your actual identifier to the remote server. So if you need to redo your auth, you just rekey and stash the new key in your authenticator (or have your authenticator originate the key material and never expose it to main memory at all).
Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.
Not quite. It's easy to create a duplicate of your metal key, and many people do exactly that to avoid a situation where they lose it and have no way of opening their door. The fact that you can't do that with USB keys is my biggest gripe with them. I understand that inability to copy even if you have physical access to the original has its security advantages, but 1) most things don't actually need that much security, and 2) it could still be done by e.g. allowing you to buy them in premanufactured batches where all keys are identical.
Somewhat personal ancedote, but I've had pretty good experiences with Yubikeys. I've had one on my daily keychain for over a decade now. Its been run through clothes washing machines too many times to count, I've left it out in rainstorms, its been baked in the sun on hot summer days multiple times, its been dropped in pools, its been run over by a car, I've dropped it some pretty significant heights while hiking. It is still working just fine. That and a PNY 16GB metal keychain flash drive have taken a ton of abuse and are still working just fine. Other than a higher melting point or ability to take high energy RF I don't imagine there is much more abuse a traditional metal key would have compared to what I've done to my Yubikey.
Maybe it’s the old USB version? I haven’t had so much luck… I had a couple of nanos, and those broke pretty quick. More recently, I switched to a usb-c version…. And while it still works and stays attached to the key ring. The plastic housing has broken already. I got a corp branded one now, that I’m trying and seems a touch more robust
I've only had the full USB-A style ones. Every device I've had that I've needed a yubikey with has either a USB-A or supported NFC. The >1 decade device is a Yubikey NEO, I recently got a Yubikey 5 USB-A variant and also have one of those FIDO-only blue Security keys in USB-A.
What kind of failures did you have for the nanos? They just became unresponsive? Did they suffer any obvious physical failure or any particular kind of event cause their failure?
If there was a NFC only version of these (and laptops came equipped with NFC), then we could make a block-of-metal key. No ports/holes and no buttons. Would be water proof and crush resistant. Assuming that you can send NFC signals through metal.
The biometric stuff is simply allowing access to the keys. It’s not being used for anything else.
Your face or fingerprint being out there isn’t a concern because that’s not, ultimately, the thing being used to generate the keys or anything.
It’s an ease of use function.
On iOS for instance, as I understand it, these are being stored in iCloud Keychain. Which has a password. The derived key for iCloud Keychain is stored in such a way that the system has access if you allow biometrics to be used.
Biometrics then simply allow access, in essence, not part of the encryption process. The password for iCloud Keychain is necessary to add those items on a new device. Your biometrics aren’t stored by Apple anywhere other than in the device.
Honestly I am blown away how few people on this site understand how this stuff works. It’s fascinating and I’m surprised more people aren’t interested in understanding it. But so many people assume the biometrics are being used in the encryption process and that if your face is somehow stolen your whole life is doomed. These features have been on Apple devices for what.. a decade almost at this point? More? The process for Face ID is the same as Touch ID. Developers make zero distinction between the two in code, as that whole process is passed off to the system and effectively results in a bool value (or access to the secure item requested). At no point does a developer ever get your biometrics data.
I don’t know how Android or Windows do it but it is similar enough I suspect.
The FUD around passkeys feels like some sort of propaganda campaign to discredit it.
Agree. I actually wanted to acquire a biometric signature to do something with it on iOS and was super bummed once I dug in to see how it works -- all Apple exposes is a function that returns true or false hahaha
This is the part where you have people dismissing a security from a simple assumption and reverting back to another assumption of their current state. Is still dangerous
Your fingerprint/faceid/whatever is used to access the passkey. It is not the passkey. To that end, yes, if you are worried about clandestine access to your phone (if that is your passkey), then you probably don't want to allow access using fingerprint/faceid. And if someone can copy your passkey off of your phone, you are again compromised.
Your faith in humanity seem low, because this would never be pushed worldwide by security experts who eats and sleeps it, if it was so easily broken where you just figures it out during a comment
This sounds, to me, like a really bad and convoluted way of storing pub/priv in a password manager, and hoping the software implementation gets it right when it's trying to manage these things for me because I'm too dumb to manage passwords and too hobbled by bad IT policies that want to change my passwords every 4 weeks.
Eh, somewhat. The lost key account recovery story is much better in large organisations, where you have a 24/7 helpdesk that can check your ID badge in person, a HR department with a photocopy of your passport, and suchlike.
But for example if you're using Azure/AD? No U2F + Password allowed, gotta go straight to "passwordless" [1].
So they never took off far enough for Microsoft to support them.
The big question I have is are the keys device/browser specific?
Seems to me I need to be able to log in with a password from any place (my phone, my machine, my office, my wifes phone, her laptop, my friends laptop, etc.).
I mean, who knows when I'll want or need to get into Something.
Also, my wife and I share accounts (such as Amazon). So, it needs to work seamlessly across all of her devices.
Then there's always the "F-with it factor" that I loathe. At least I understand passwords. Can (mostly) always recover a password (I recall trying to recover my Apple ID password -- they bluntly said "ok, but you have to come back in 2 weeks", so I was locked out for 2 weeks).
And, of course the level of patience my wife has with Technology is less than zero.
I rely on my Safari auto fill, when I use another browser, I just copy the pw from Safari.
And I don't use any of the cloud services. I have an iPhone, but don't use iCloud.
A few weeks ago, I was unable to log in to Google on a new device with my 2FA token (Yubikey) because Google insisted on authenticating with a passkey/resident key, but the token had only been set up with non-resident TOTP or whatever it's called (and had been working properly in this mode for over a year). I was able to log in on another device and register the Yubikey with a passkey/resident key, but it was really scary! There is so much complexity here, and so little visibility and control afforded to users, that I feel very uncomfortable trusting it as my only login method for any moderately important service.
It's possible this was a Mac OS problem, but I don't think it really matters. Either way, this stuff needs to be absolutely rock solid and frictionless if normal people are going to use it safely, and it obviously isn't.
It's a Google sign-in workflow problem. I've seen the same issue more than once - for whatever reason it decides that this one way of signing in is the one that you want to use right now, and it can be impossible to back out until some timeout kicks in.
I'm not entirely sure Google is trying to "make it right" so much so as funnel users to its own products (i.e. Android devices and Google Authenticator).
The super simple explanation is: SSH keys for websites.
You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc).
The website only gets the public key, so unlike password auth your secret is never given to the website.
When accessing that website, the website can send a challenge which your browser answers using your private key associated with that specific domain.
(I'm not a passkey expert and there are a lot more technical details to this, but this is my 10,000ft mental model of what's going on)
It's still not a great multi-platform/multi-device story. I use multiple machines regularly (and I've migrated away from 1Password to the KeePass ecosystem, by the way) so syncing passkeys from my Mac(s) to my iPad, to my Fedora machines and my Windows working environment is simply not happening any way I look at it.
Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.
You shouldn't ~~necessarily~~ need to "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.
Similar to SSH keys. No reason to use the same key on all your machines, use a different key from different places.
The passkeys on my laptop are different from the passkeys on my desktop which are different from the passkeys on my phone which are different from the passkeys on my main yubikey which are different from the passkeys on my backup yubikey.
Edited due to acknowledging people may choose a variety of alternative workflows.
> You shouldn't necessarily "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.
If he's storing his passkey in his password manager, it wouldn't matter that he lost the device. They can't get to it, it's AES-somebigassnumber-ed up the wazoo. If the passkey is cached outside of the password manager, then passkeys are a horrible idea, where you have to "go home and call the 800 numbers to cancel the credit cards", and worse still, people with few devices might end up in circumstances where they have no valid devices left to bootstrap access.
I am resigned to the fact that I will die with humanity never having solved the problem of passwords adequately, but being that I will live another two decades minimum, I will get to see two more of the stupidest possible non-solutions.
That's assuming the user does have a strong passphrase to protect their local password safe and the device wasn't compromised while the password safe was in an unlocked state.
If an attacker managed to get root on my machine right now, they'd get my whole password safe as its currently decrypted and in memory. However, they wouldn't be able to access any of my passkeys.
And if they get the passkey's private key, when you're signing some ticket to send off to prove identity? That has to be unlocked for that too, it's in memory somewhere.
Then they privilege escalate, lock out all your other devices after adding a new one, it's the same issue. And it's opaque, reinforces the ideas that users are too stupid to do anything right, so that we shouldn't even try.
> That has to be unlocked for that too, it's in memory somewhere.
Its in-memory on my physical hardware token or a TPM or a secure-enclave, which only activates and unlocks after a valid identity challenge (fingerprint, physical touch, face scan, pin, etc.) not my main system's userspace memory. A massively different target.
I use far more sites than I ssh into servers, which makes this much more of a pain. Like, every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop? If all my devices are destroyed in a house fire again, I'm locked out of everything? These have been my big concerns.
> every time I sign up to a site I need to grab all 5+ devices I might ever use and add them to every site, or I can't e.g. log into my D&D game while travelling because I forgot to generate a key on the work laptop?
You don't need to log in to every app on every device the instant you register a new account. Just make a passkey on a couple of devices that you're likely to have around and you'll probably have what you need when you need it. When I register on a new site that uses passkeys, I might create a key on whatever computer I'm on and a portable authenticator like my phone or my security token.
So, say I'm at home on my deskop, and TotallyCoolService has the option for a passkey. I'll make one on my desktop, and then go ahead and make one on my security token. Later I'm out and I want to check in on TotallyCoolService on my phone. No worries, I just tap my security token to my phone and I'm logged in. Later I'm in the garage working on my motorcycle and want to reference something on TotallyCoolService on my laptop and my USB token is in my backpack inside. No problem, I can sign in with my phone. Now I've got security tokens on most of my common devices and its not like I had to spend time gathering all of them at account creation.
I don't instantly run home to my desktop and log in the moment I sign up for a new site while out and about. But I do go and sign in eventually, even if only to ensure there's a backup key there.
This really doesn't contradict the problem of needing to sort out M sites x N devices, where M can be very large.
Whether you do it eventually or do it straight away. Unless you can predict which devices you will have and which sites you will need access to at any given point, then it degrades to needing everything authenticated just in case.
I'm pretty much never too far from either my phone and my security key, seeing as how at least my phone is my car key and my wallet the majority of the time and a security key lives in my backpack.
Sure, M devices can be quite large, but the odds of me being at only one device and not any of my portable devices is extremely small. As long as I have at least one other device I've previously logged in to somewhat handy, I can still easily get in. Maybe that initial login is marginally more complicated, but IMO the ease of future authentications more than makes up for the small bit of initial friction the first time.
And in the rare instance where I'm suddenly on the moon and realize I left practically every other computing device and physical authenticator on another planet, I guess I just won't have access to a DnD tool. Oh well.
> No worries, I just tap my security token to my phone and I'm logged in.
What allows you to tap your token on your phone and register a passkey-stored-on-phone registered with TotallyCoolService? Did you previously set your phone and token to be "mutually trusted devices" in some way?
Or what's preventing a thief from tapping my token on their phone to register it on TotallyCoolService?
I see. So the weakest link in the security chain is that someone discovers the <6 digit pin on your usb key (easy on a security camera), and then manages to steal it for 2 min.
Not terrible for anyone whose threat model is not targeted attacks. But quite bad for people whose threat model is exactly that.
Great in theory, but in practice there are still a frustrating amount of websites and services that put a low upper limit (usually just one or two) of the number of keys you can enroll.
This effectively makes it impossible to do what you’re saying. It sucks.
I hear this a lot but it hasn't generally been my experience. The only site I've personally come across that supports webauthn/passkeys but doesn't support multiple is the AWS management page. Which I essentially bypass by just configuring SSO and using an IdP which does support it.
Every other site I've come across that supports these things supports multiple. What common sites support only one or two?
Yo. Thank you so much for posting in this thread. Turns out I was thinking about Passkeys wrong this whole time and you're the first person (I've seen) to really explain this workflow. Thanks again!
Actually, I much prefer to use the same SSH key for deployments from any of my machines, so that example doesn't really work for me (I do have multiple keys).
The first time I log in to a service on a new device it'll prompt me to sign a challenge with a previous passkey. If I've got my yubikey handy I'll just plug it in and sign it and add a new passkey to my new device. If I only have my phone the site will flash up a QR code I scan with my phone which signs and posts back the proof to a callback URL for the site. I only need to do this once per device if I add a passkey to the device.
Is the fact that you need access to an already- enrolled device to create additional passkeys part of the threat model that passkeys resolves, or just an annoying detail? And is this for every site, or just once per device? I can just look it up, this thread has been great to improve my mental model enough to start considering trusting it.
Its per-site. So the first time I log into GitHub on a new device, I need to do the handshake with another device. The first time I sign into Coinbase, I need to do the handshake with the other device.
So this typically means when I get a new device I'll have my Yubikey in a bag or something with me for a while and pull it out from time to time. Eventually practically every site I use gets enrolled on the new device and I never actually need to reach for the Yubikey or my phone or whatever.
I don't really make any concerted effort to go through each and every account when I get a new device, it'll pretty much just happen eventually. When I do sign up for a new account that supports passkeys I do try and make an effort make a passkey on at least two devices though, often at least whatever device I'm using to initially register and my yubikey. Then I'll make a point to log in sometime in the next few weeks on another computer and create a passkey there. Eventually I'll probably end up logging in and making passkeys on most of my devices.
Needing to auth with an existing passkey is a major part of the model. If you could just log in and create a new passkey with just a regular password, what's the point?
I've installed KeePassXC on my Mac and Linux machines and it stores Passkeys. Low-tech syncing is by Signal Notes to Self. If there were an audited app for iPhones I'd still be using that method; there isn't, so I've moved to Bitwarden. Passkeys seems to work fine on Bitwarden.
I currently use the 1Password passkeys, and when they work, it's pretty good. I get all the fun of showing up on a website, and with three clicks, I'm in. But I've used them on just a few websites (email and GitHub), and they work correctly maybe 10% of the time.
First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.
At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).
PS: Why is it that no financial institution lets you use anything more than a SMS U2F?
How do you back up the private key? With ssh I know to back up .ssh with the rest of my home folder. With a passkey I'd have no idea where it was, and get the feeling the "modern" software won't tell me on purpose, so that it can manage/sync it for me. Which leads to a lack of a mental model.
KeePassXC is not Big Tech. It is open source and self-hosted. It supports exporting the private keys, although Big Tech is not happy about that feature: https://news.ycombinator.com/item?id=40167782
Nice phrasing, I lack that mental model as well. Anyone here willing to distill down the whole thing to a few sentences? Who stores what kind of secret, and is there some kind of challenge/response at auth time?
A physical device which is not your computer stores some secret information which can authenticate you. This can be passwords, passkeys, GPG keys, your retina etc.
The physical device can be password protected. So you have two step authentication:
1. your physical device
2. your password to that device
Phones are currently being promoted for various reasons, but I believe something like Yubikeys or other FIDO2 fobs will be a better device. You can have multiple of them, you can store one of them in your bank safe. Someone stealing it of you is proper theft which can be traced in a usual manner by police. Stealing is not enough because you still need the password. The difficulty of asking you for password remains equal to difficulty of hitting you with a wrench. You don't need to remember stuff anymore, because you can just use your physical keys. You will need to travel with those keys, but its just same as your house keys. It is probably an extra key in your key fob.
To add to it, the U2F/FIDO2 standard will make it vendor independent, and so no lock-in.
What I find rather confusing is what happens on each device. There appear to be multiple places where passkeys can get stored (iCloud Keychain, Google account, Chrome profile, Bitwarden, ...?) and depending on where it's stored it may or may not get synced to various other devices, browsers and apps.
So my problem is that I keep forgetting which device, browser or app I used when I created a particular passkey. I'm never asked where I want to store a particular passkey and where I want it to be available. This is all an implicit function of a combination of factors apparently.
It's like misplacing my keys has been taken to a whole new level of abstraction :-)
Many places let you enter and name multiple passkeys. So you as your keychain one and name it "keychain". And also add phone and call it "whatever phone" then use either.
Personally I only use devices that don't sync and can't be copied for security reasons.
Safari on macOS uses passkeys without phone. So unless you consider security chip inside macbook a separate device, that's not true, that's just one of modes.
Thanks! A bit late to the party, but if you still see this, I presume the authentication exchange between the web server and the device is some kind of challenge response? And if so, does the challenge/response depend on the type of credential that's in the device?
Back when I implemented webauthn for the first time I remember the interactive tutorial webauthn.me provided by Auth0 was very helpful in wrapping my head around the process.
Most important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!
The signed assertion includes the clientDataJSON, which contains the origin of the relying party. Assuming the server properly validates that assertion, it should prevent the use of a phished assertion by a third party.
Nice to hear I'm not the only one. Part of the problem is that it's always presented post-login when I'm already in the middle of doing something. And my password manager works well, so I don't see a clear benefit and I'm not really motivated to investigate vague claims.
I agree, plus the added abrasion from passkeys being implemented inconsistently and seemingly in a way that promotes vendor lock-in. Do I need a different passkey for my iPhone and an android tablet? Do I need a different passkey between iOS devices? Why does this service allow me to use a passkey in Bitwarden, but that service doesn't? These are all questions I've never had to ask about a complex password in a password manager.
The primary advantages of passkeys are phishing resistance, uniqueness per site, and breach resistance.
Phishing resistance is improved over what a good password manager can provide (unique passwords per site, checking web origin before providing options). Since WebAuthn is a protocol, the origin of the requesting site is stamped into the authentication response; even if the user had the option to override a passkey to be sent to a different malicious domain, it is meant to be rejected if replayed on the legitimate website. WebAuthn really needs an attacker to compromise the legitimate site or to compromise DNS and TLS infrastructure for phishing to be successful.
The uniqueness is really two benefits in one - you don't need to think of multiple unique passwords (if doing manual password management), or suffer with password complexity rules (if doing either manual or automated password management). It is just a public key, usually a P-256 curve point. The security of the user authentication process is abstracted upstream, so it is secured with the local password/biometric or via an activation PIN (same as password managers).
The breach resistance means that if XSS gets onto the page, if a hacker gets read-only access to the password database, it is still infeasible for them to leverage anything they gain to answer future authentication challenges. If your passwords aren't unique, a breach is a big deal and can create a lot of lateral movement. Even if they are unique, attacker visibility of the password means account compromise. The private key in a passkey is separate from the website infrastructure, so that attacker is not going to be able to authenticate from anything they observe.
>All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and you still have to do some stuff if the other side (service provider) gets hacked. If we used bog standard pub/priv keys instead, then everything could become universally better. There'd be no need to worry about password policies, whether there is a character limit or not, how well and consistently individuals handle it, or anything like that ever again. Nor care if a site is breached, literally no action required because the site would only have the public key, they could publish it in clear text and it still wouldn't help attackers authenticate a single iota. Plus things like phishing and so on go away, because same thing, if the user has their agent browser to a malicious link or the like, and then it presents their pubkey, it still wouldn't do anything and the agent can't be fooled by similar looking to humans domains or anything. The agent would expect the service to present the proper signed request and anything else wouldn't work. Conceptually everything could be automated and standard without any sort of silo, all software could speak the same standard simple key format and everyone could back that up and sync it any way they wanted.
Unfortunately as is so often the case these days there's a lot of perverse incentives and players who can't resist the urge to try to add extra functionality in on top rather then just going for the low hanging fruit in a solid way first. So we've seen a confusing muddle, of existing players with financial interests who make money by helping lower the pain of the garbage that is password based mutal auth, those who see new chances to try to silo, those who want to shove in attestation and differences in password backing for good and bad reasons, mixing in concepts of hardware backing that are unnecessary, etc. I'm still hopeful something will come out of it in the end but it's been a real bummer to see how it's played out.
Yes but what I'm still confused about is that:
1) Is one/some of your public key reused on different services
2) Or is there a different public key for each service
1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password
2) In the second case when one service is breached you'd still have to manage rotation of public key somehow, how trivially is that done with current implementation ?
>2) In the second case when one service is breached you'd still have to manage rotation of public key somehow
Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.
If I have any fear that the associated private key have leaked. For instance if my off-site encrypted backup is stolen. I sure would want to rotate my private key because my secret would be only as safe as the encryption method at the time the backup was stolen. I'm still not entirely sold on the "quantum will break any current crypto" but better safe than sorry.
>If I have any fear that the associated private key have leaked. For instance if my off-site encrypted backup is stolen.
That sounds like a totally separate threat compared to "when one service is breached". In your last comment you were talking about your password manager being hacked, but in the post before that you were talking about the service (ie. the website you're using) being hacked?
Also, while I do agree that if your your password manager database were hacked you would need to rotate both passwords and passkeys, but I would hope that occurs far less frequently than some random service you use getting hacked.
The whole point of a public key is that it is not secret. A breach where a service leaks the public keys of its users does not harm your security posture at all.
The problem Passkeys (and FIDO2 and WebAuthn and U2F) solve is phishing. The core concept is mutual authentication: not just you to the service, but the service to your authenticator.
Totally agree. I have used fido2 and webauthn before and I liked it. Particularly with a hardware key the mental model is quite straightforward. Now with that Microsoft, Google and syncing business I am left totally confused. Why the hell should alI store a private key in some cloud?? What happens if that provider decides to terminate my account, if it gets pressured to release the key? Also how does this all work with Windows Hello and other things in between??? I know a bit of crypto and security protocola but the passkey concept and possible attack vectors totally escape me.
I agree, framing it as a mental model makes sense.
Here’s the issue: when a site rejects my password, I understand the potential reasons—wrong site, wrong account, or forgotten password update. But what does it mean when a passkey fails? How can I resolve this? Is it even fixable?
My lone attempt to use a passkey for login involved an unrecognized fingerprint authentication, leading to repeated failures and ultimately, a return to traditional passwords due to the opaque nature of passkeys.
What the parent says. I'm hoping this HN thread will help clarify this.
Currently, I view the entire paradigm as asking me to trust resources (software, hosting, etc.) that I am not ready to trust. Both from a knowledge standpoint, or lack thereof on my part, and out of experience. Re the latter, third party resources die, go bad -- technically or morally -- and... just observing the nature of "online" resources over years and now decades.
They’re basically an advanced username/password that’s automatically generated by your device. I believe one of the benefits is they require an encryption component that is known only by the devices that you own. This is better than a password that’s stored on a server and can be lost.
It is a different technology with some different edge cases so I wouldn't call it a rebranding but in the broad scope yes. The problem with this stuff was always the integration, not the tech.
The mental model is very simple. If you use things like Yubikey, it is exactly like a key you use to start your car. A single password protected key maybe. In essence, it is your password manager but something that everyone can use. And something that doesn't need to be on the cloud.
It is like a key to start your car, except you can register it with multiple cars. And it has 25 or so "slots" for car registrations. If you lose the key, you cannot order a copy from the car manufacturer. You also cannot make a copy yourself. But you can (usually) register multiple keys with the same car. You do this by plugging two keys into the same car, and the car learns both keys belong to the same owner. You just have to be careful and keep track of which car is registered with which key, and vice-versa. Sometimes the key will not work with a particular car. Also, after you plug in the key, the car will not start right away. It will first ask you to select which key to use. If you use Bitwarden, it may hijack the key insertion interaction and will offer to use its soft-key instead. So, some small differences ;-)
Well that doesn't help understand: How passkeys can be backed up? Where/how they are stored? What if I loose my phone, computer? How can I login to some app using pc/mobile?
I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.
The TL;DR version in my opinion is that passkeys are quite similar to a SSH key pair, like one you'd use on GitHub. Basically you generate a key pair, the server stores the public key, and the client stores the private key. When you want to authenticate, the server sends a challenge, you sign it with your private key, and send it back. The main debate is over how to manage those keys after generation.
- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.
- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.
The big problem is that most passkey providers do not support actually giving users their passkeys.
As the article stated: "I want you to remember this quote and it's implications. Users should be able to use any device they choose without penalty."
As you've pointed out:
>> Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
and again:
>> Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up.
How can I get my passkeys and back them up on my own storage media? (e.g. USB drive, encrypted cloud storage, burn to a disc, etc.)
How can I import passkeys generated elsewhere?
If you cannot backup or import the passkeys, then you do not control them. They are not your passkeys--they belong to Google or Apple, etc.
And as the article states, in most cases these passkey providers do a piss poor job of managing their passkeys that they claim belong to you.
Agreed, they unfortunately seem to have gone the vendor lock-in route. The big players don't have export utilities for passkeys, despite it being technically feasible and pretty straightforward to implement. That's a pretty major gap in the spec, there should be a standard export/import format, and vendors should be required to implement it in order to be compliant.
It's probably possible to extract passkeys from a rooted Android device, but it would definitely be out of the grasp of 99% of users. I have not looked into it in detail, but I'd expect a Frida script hooking the keystore decryption function would get the raw data, then it would be a question of interpreting whatever proprietary format Google is using for their password manager.
This has always been my objection to them, as a user, as they have been presented. As an employee, I don't care. Businesses have sufficient relationships and mechanisms to self-serve any issues that come up, like lost keys. But as a user, I do not. It is a drop-dead requirement for me for any authentication material that I have some way of backing it up and modifying it in case of compromise.
Besides, give the Silicon Valley venture capitalists and Harvard MBA bros a whiff of the possibility of full control over something as important as your primary authentication material and before you can whisper Richard Stallman they're out having a happy Bacchanalia toasting the name of Portunus [1], whom I will now resurrect out of our ancient past to name him the God of Platform Lockin, and us users aren't going to get a word in edgewise over the debauchery and slides projecting Total Addressable Markets.
Fortunately it seems they all got a little too drunk with power this time, but honestly it's only a matter of time before they arrange another Portunus summoning lock-in party again. This target is irresistible and the annoyance people have with passwords is too good an angle to pass up.
I'm not quite sure if even the corporate case works properly with iOS & Android devices as the article states, otherwise you could become a 'corporation of one' and side step all of this stuff. Even the corporations look like they have to use apple or google's crap for employee devices and accounts?
I mean in principle. If I throw my authentication material into a lake, there's an IT department that can have authorization to re-establish it. If I throw my personal authentication material into a lake, there's really nobody who can help me. I can try to convince a large company that I'm really me, but that is indistinguishable to them from a social engineering attempt, and dealing with that is high touch and expensive. I need to be able to back up my stuff. If the aforementioned "large company" is the one holding my authentication material and anything whatsoever bobbles it, then I'm back to trying to convince them I'm me.
A "corporation of one" is still just me, so I'm not talking about trying to technically hack around things by pretending to be a corporation.
When you see it this way it becomes really clear that Google, as a corporation, is an absolutely atrociously awful company to be the ones holding the keys to my identity. But there aren't any good, big, easy, safe options. I need to be able to self-service. Or we need to create much smaller, more local (in some sense, not necessarily geographical) holders of the auth material that I can convince I am me and they can reset it if something goes wrong. But that gets into a complicated web-of-trust and that's never worked out.
I reread your analogy a few times, and while I think it's probably accurate, there is absolutely nothing simple in it. It reminds me of the "It's like Uber, but for mortgage insurances" kind of startup pitch. It perfectly encapsulates the concept, but the concept itself is just crazy niche.
To note: the key to start a car is provided with the car with no specific operation, is locked to no other device, doesn't care about who's handling it, can be duplicated and passed around. It would be closer to the traditional password system in all of its aspects IMHO.
I understand passkeys as authentication through a private/public key generated by the client when creating the credential, with the private key staying client side and the public key kept server side, with some more details around it to make the whole thing discoverable/automatable.
To me the best explanation was just to go to the passkeys.io site, the subject is complicated enough that analogies tend to introduce a lot of cognitive noise IMHO.
I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not integrate well with password less so it’s best to stay where I am until things settle out better.