11 ms·

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

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.

geertj 3y ago
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?
- triblemaster 3y ago
  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.
  - vbezhenar 3y ago
    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.
    - triblemaster 3y ago
      Security chip inside macbook is a separate device for authentication purposes if it needs to be unlocked and cannot be bypassed by the OS.
  - fauigerzigerk 3y ago
    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 :-)
    - postalrat 3y ago
      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.
  - marssaxman 3y ago
    There's something here I am not following. First you say: > Stealing is not enough because you still need the password. But then: > You don't need to remember stuff anymore, because you can just use your physical keys. How are these statements both true?
  - geertj 3y ago
    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?
- Huppie 3y ago
  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.
- kriops 3y ago
  Most important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!
  - dboreham 3y ago
    Not true.
    - pseudo0 3y ago
      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. https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
triblemaster 3y ago
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.
- alt227 3y ago
  Apologies I dont mean to be rude, but this does not help me conceptualise passkeys in the slightest.
  - triblemaster 3y ago
    https://news.ycombinator.com/item?id=40168230 https://news.ycombinator.com/item?id=40168230
- jve 3y ago
  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.
  - triblemaster 3y ago
    https://news.ycombinator.com/item?id=40168230 https://news.ycombinator.com/item?id=40168230
  - pseudo0 3y ago
    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. Here's a good fairly high-level breakdown of how it all works, if you want some additional detail: https://webauthn.wtf/how-it-works/authentication https://webauthn.wtf/how-it-works/authentication
xoa 3y ago
>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.
- joshstrange 3y ago
  Thank you for that description. I do understand at a high level that it’s similar to SSH keys with the pub/private aspect. I think I really need to implement it myself at least once to really grasp it. Maybe that’s stupid/slow of me but that’s how I learn best.
michaelt 3y ago
> 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.
- chrisweekly 3y ago
  > "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.
acheron 3y ago
Yeah I’m not sure what’s going on either. Is this just a rebranding of mutual-auth SSL client certs?
- dboreham 3y ago
  Kind of. With the sharp edges filed off. There's no CA though. The web site provisions and authorizes the client's key at onboarding.
  - acheron 3y ago
    ohh, I see. that's clearer than any other explanation I've seen, thanks.
- UncleMeat 3y ago
  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.
stetrain 3y ago
You can store passkeys in a password manager as well: https://1password.com/product/passkeys https://1password.com/product/passkeys 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)
- MadVikingGod 3y ago
  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?
- rcarmo 3y ago
  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. They're just not mature yet, period.
Timothee 3y ago
I’m in the same place. 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.
- yunwal 3y ago
  > 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.
  - OkGoDoIt 3y ago
    That’s my problem with TOTP second factor authentication. I’ve used Authy for years because it works on Windows and mobile, but now they’ve decided they aren’t going to work on Windows anymore (but they still force update a perfectly working Windows app and there’s no way to opt out). I have no way to export my 30+ TOTP accounts to a new system. I often don’t want to have my phone around when I’m trying to focus and get work done, but now I have no choice. It’s infuriating. Is there any cross-platform TOTP system that has the ability to export your keys? Is that even a thing that’s technically feasible?
  - mrtesthah 3y ago
    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. So those are the real risks.
pimlottc 3y ago
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.
- flkiwi 3y ago
  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.
m3kw9 3y ago
Having a mental model of encryption has never improved security
SkyPuncher 3y ago
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.
dfabulich 3y ago
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.
- CogitoCogito 3y ago
  Do you know if there an open source self-hosted implementation available?
  - caconym_ 3y ago
    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.
Edmond 3y ago
Here's a primer on the basic idea: https://blog.codesolvent.com/2015/07/why-not-signed-password-authentication.html https://blog.codesolvent.com/2015/07/why-not-signed-password...
caconym_ 3y ago
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.
- int_19h 3y ago
  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.
  - gunapologist99 3y ago
    If even Google can't get it right...
    - int_19h 3y ago
      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).
tptacek 3y ago
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.
nomagicbullet 3y ago
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. For now, I’ll stick with what I understand.
dwaite 3y ago
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.
pbnjeh 3y ago
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.
deleted 3y ago
[deleted]
riedel 3y ago
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.

geertj 3y ago

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?

triblemaster 3y ago
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.
- vbezhenar 3y ago
  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.
  - triblemaster 3y ago
    Security chip inside macbook is a separate device for authentication purposes if it needs to be unlocked and cannot be bypassed by the OS.
- fauigerzigerk 3y ago
  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 :-)
  - postalrat 3y ago
    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.
- marssaxman 3y ago
  There's something here I am not following. First you say: > Stealing is not enough because you still need the password. But then: > You don't need to remember stuff anymore, because you can just use your physical keys. How are these statements both true?
- geertj 3y ago
  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?
Huppie 3y ago
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.
kriops 3y ago
Most important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!
- dboreham 3y ago
  Not true.
  - pseudo0 3y ago
    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. https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...

triblemaster 3y ago

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.

alt227 3y ago
Apologies I dont mean to be rude, but this does not help me conceptualise passkeys in the slightest.
- triblemaster 3y ago
  https://news.ycombinator.com/item?id=40168230 https://news.ycombinator.com/item?id=40168230
jve 3y ago
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.
- triblemaster 3y ago
  https://news.ycombinator.com/item?id=40168230 https://news.ycombinator.com/item?id=40168230
- pseudo0 3y ago
  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. Here's a good fairly high-level breakdown of how it all works, if you want some additional detail: https://webauthn.wtf/how-it-works/authentication https://webauthn.wtf/how-it-works/authentication

xoa 3y ago

>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.

joshstrange 3y ago
Thank you for that description. I do understand at a high level that it’s similar to SSH keys with the pub/private aspect. I think I really need to implement it myself at least once to really grasp it. Maybe that’s stupid/slow of me but that’s how I learn best.

michaelt 3y ago

> 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.

chrisweekly 3y ago
> "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.

acheron 3y ago

Yeah I’m not sure what’s going on either. Is this just a rebranding of mutual-auth SSL client certs?

dboreham 3y ago
Kind of. With the sharp edges filed off. There's no CA though. The web site provisions and authorizes the client's key at onboarding.
- acheron 3y ago
  ohh, I see. that's clearer than any other explanation I've seen, thanks.
UncleMeat 3y ago
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.

stetrain 3y ago

You can store passkeys in a password manager as well: https://1password.com/product/passkeys https://1password.com/product/passkeys 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)

MadVikingGod 3y ago
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?
rcarmo 3y ago
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. They're just not mature yet, period.

Timothee 3y ago

I’m in the same place. 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.

yunwal 3y ago
> 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.
- OkGoDoIt 3y ago
  That’s my problem with TOTP second factor authentication. I’ve used Authy for years because it works on Windows and mobile, but now they’ve decided they aren’t going to work on Windows anymore (but they still force update a perfectly working Windows app and there’s no way to opt out). I have no way to export my 30+ TOTP accounts to a new system. I often don’t want to have my phone around when I’m trying to focus and get work done, but now I have no choice. It’s infuriating. Is there any cross-platform TOTP system that has the ability to export your keys? Is that even a thing that’s technically feasible?
- mrtesthah 3y ago
  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. So those are the real risks.

pimlottc 3y ago

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.

flkiwi 3y ago
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.

m3kw9 3y ago

Having a mental model of encryption has never improved security

SkyPuncher 3y ago

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.

dfabulich 3y ago

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.

CogitoCogito 3y ago
Do you know if there an open source self-hosted implementation available?
- caconym_ 3y ago
  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.

Edmond 3y ago

Here's a primer on the basic idea: https://blog.codesolvent.com/2015/07/why-not-signed-password-authentication.html https://blog.codesolvent.com/2015/07/why-not-signed-password...

caconym_ 3y ago

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.

int_19h 3y ago
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.
- gunapologist99 3y ago
  If even Google can't get it right...
  - int_19h 3y ago
    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).

tptacek 3y ago

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.

nomagicbullet 3y ago

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. For now, I’ll stick with what I understand.

dwaite 3y ago

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.

pbnjeh 3y ago

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.

deleted 3y ago

[deleted]

riedel 3y ago

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.