10 ms·

Passkeys are just passwords that require a password manager

156 points by dfabulich 1y ago

JohnFen 1y ago
> To present a passkey, you have to use a password manager. This is what makes passkeys nonstarters for me.
- aldshglkhdg 1y ago
  that isn't true at all. i regularly use a yubikey as a passkey, and it's entirely orthogonal to any password manager i use. it happily just works on firefox on both mac and linux. to use a passkey, you need a place to store the passkey. that can be a hardware token, a tpm, or a password manager.
  - deleted 1y ago
    [deleted]
  - blindriver 1y ago
    What is someone steals your backpack with your laptop and all your yubikeys, your phone, etc? How do you get back your access?
    - dfedbeef 1y ago
      Don't keep all of your yubikeys and phones and laptops in one bag.
      - int_19h 1y ago
        Unfortunately, many services don't allow you to register multiple passkeys, so having a backup key that is stored somewhere safe is simply not an option.
        chipsrafferty 1y ago
        That's why you have multiple passkeys that have the same key. It's a physical backup, not a software backup.
        crote 1y ago
        ... at which point you lose the whole "something you have" part of 2FA. If they all have the same key, it is impossible to distinguish between individual copies, so the compromise of a single copy is impossible to detect. Additionally, you can't revoke a single copy: you are now forced to revoke all of them at once.
        xg15 1y ago
        > Unfortunately, many services don't allow you to register multiple passkeys Doesn't this already make that scenario a nonstarter? I can't revoke individual keys if I can only register one key in the first place.
        esseph 1y ago
        You can revoke individual ones.
        rcxdude 1y ago
        Is that what you have set up? Can you describe how you do it in more detail? I'm looking for an option like this but everything I've found seems to suggest it's not possible (or at the very least wildly impractical). I'm looking for something where it's at least possible to make a physical backup that's still relatively secure.
        dfedbeef 1y ago
        You only need multiple on your recovery email. Unless you're using Yahoo or running your own email server, this is an option.
        dfedbeef 1y ago
        It might be possible to set it up on a home server idk. I would rather waste my time on other stupid things.
      - blindriver 1y ago
        That doesn’t answer the question, unless it means you’re SOL. If that’s the case why on earth would I prefer passkeys to regular passwords as long as I practice safe password handling?
        dfedbeef 1y ago
        Do whatever you want. It's easier for me to have a primary recovery email and password manager with MFA that uses a yubikey and phone authenticator. Then I can use passkeys or whatever for the rest of the stupid accounts that I don't care about. Side note: I feel like people always say 'i can just use good passwords' and then their password is like '<sports reference><year>'
    - chipsrafferty 1y ago
      Don't bring anythng you really wouldn't want to get stolen anywhere outside of your house.
      - blindriver 1y ago
        What if your house burns down with all your contents? My point being, there is a reasonable limit to how many physical passkeys a person would make but there’s also a non-zero possibility that a physical catastrophe could occur that destroys all the passkeys. What happens in that case? Can you recover your accounts?
        tzs 1y ago
        Most sites currently have you create your account with a password, and then later you can add passkeys. If you still have your passwords after your house burns down you can use those to get into sites. If your house burning down also wiped out wherever you store your passwords, you'd use whatever mechanism each site provides for recovering from a lost password.
  - JohnFen 1y ago
    Yubikeys are an even worse solution, in my opinion. They dramatically increase the amount of hassle and maintenance required because you have to have multiples of them to ensure that you won't get locked out. Also, it's not always convenient or possible to plug something into a machine you're using. > to use a passkey, you need a place to store the passkey. Yes, and any place that requires me to use particular piece of software, machine, or device is a real friction point for me.
- dylan604 1y ago
  Are you not already using password manager for all of your passwords? It took forever to make any movement towards getting people to stop using the same password every where. Now we're telling people passwords aren't secure even with using a password manager and they should use passkeys. So now we're saying that using the same software that we spent so much time suggesting to use is not good enough. Instead, now you want them to use a dedicated piece of hardware that needs to never be lost, but people lose their phones frequently. It's amazing to me how the majority of readers here absolutely cannot put themself in the place of non-computer nerds that spend 0% of their day thinking about code/security or anything other than what the Kardashiens are doing or their favorite influencer or whatever other nonsense that is everything and not nonsense to them. It's this kind of thinking that put us in this position that the people building the thing can't think about how the users will actually use it
  - XorNot 1y ago
    That's not the problem: the problem is if I change password managers, or move software or any of many other possible things, whereas with password I can just type them into the new thing in the worst case...passkeys are wholly opaque. The ability to migrate them was considered an optional feature and not implemented before they were launched. It's still wholly unclear whether any individual implementation will let you do that or not, with options to prevent it.
    - dylan604 1y ago
      Again, it's us nerds making thing that didn't make it well enough that it causes pain on the end users. Not really sure how that's not the problem.
      - porridgeraisin 1y ago
        Standards/specs set incentives which uniquely decide implementation quality. If after many years implementations backed by a variety of funding and brains _all_ suck, then it's the standard/spec's problem.
  - 1y ago
- chipsrafferty 1y ago
  It's not true at all. Not many apps support passkeys, but for the ones that do, it's a godsend. No longer do I have to worry about whether my password is stored in Google, or Firefox, or if it's up to date, or what happens if I get hacked. I just plug my little key into the computer and tap it. It's like having a physical key instead of having your password written in a page of an obscure book in the library. Probably safe, but someone dedicated can find it. A physical key can only be taken if my house gets robbed.
  - eviks 1y ago
    > No longer do I have to worry about whether my password is stored in Google, or Firefox You never have too worry about it with a password manager, and also don't need to worry whether your key is plugged in in the computer you're currently using
  - rcxdude 1y ago
    > No longer do I have to worry about whether my password is stored in Google, or Firefox Once Google and Firefox start pushing their passkey implementation, you do. One issue with them is user confusion about where the passkey is stored. And do you have a backup solution for if you lose your physical key? That's the big problem I have in practice at the moment: I would like a physical device for storing credentials, but I 100% cannot have it as a single point of failure. Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them!.
    - tzs 1y ago
      > Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them! • You can use multiple independent cloud sync vendors. When I add passkeys to an account I add two passkeys. One gets stored in 1Password and synced using their cloud. The other gets stored in Apple's Password and synced using Apple's cloud. This should give you enough redundancy to mitigate most vendor lock-in concerns. • If using devices that don't cloud sync I don't see why your would need to carry around two devices in order to enroll two devices. Carry around one device, and when you make a new account create a passkey for that account stored in the device. Later, back home, login into any accounts you created while away using the passkeys on the device you were carrying, and create a second passkey on each of those accounts and store it on the other device.
- esseph 1y ago
  How do you plan to sync your passkey between devices? Another feature of the password manager.
lazzlazzlazz 1y ago
The fact that you can't actually see the passkey is absurd. I understand it's a "feature" prevent phishing — victims have a lot less to share — but it constrains more sophisticated storage and use of passwords.
- shmerl 1y ago
  Their spec doesn't dictate that you shouldn't be able to see it. It's just dumb implementations that do it (mostly for lock-in purposes). There are ones where you can see it just fine.
  - Gigachad 1y ago
    It's not for lock in, it's for anti phishing purposes. Passkey managers are designed so that grandma on the phone to a scammer can't physically dump and email her entire passkey vault. It's impossible to get phished by a fake login page with Passkeys and it's impossible to send your private keys to someone on the mainstream Passkey managers. Portability between Passkey managers is still an issue though. Last I checked there were in draft specs for migrating between managers but nothing ready yet.
    - shmerl 1y ago
      Not being able to see it all can't be justified with "for phishing purposes". You can put a big warning there that exposing your private key is a risk, but user should be able to see it with needed effort. Not being able to see it at all is a problem, like anything that moves away control from the user to some external entity. Of course they'll happily justify it with security reasons, but that doesn't remove the problem.
      - Gigachad 1y ago
        The person on the phone will just instruct grandma to ignore the warning and that it's important she continue and send the private key over to secure her account. Considering there isn't really anything you can do with the private key other than logging in to a website, making phishing impossible is a higher priority than letting people view the keys. There are alternative open source passkey managers which do let you view them. But it seems pretty obvious the average person is much better off not having this.
Darkskiez 1y ago
Except you can store the passwords on a usb key / remote over bluetooth, and then also keep them secret from the potentially compromised host.
- gnabgib 1y ago
  The first passkeys were physical (USB) keys. And you never share the key with a host or server.
commandersaki 1y ago
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login, but the site/app has no way of knowing/proving whether that happened; they just get the password. Thought sites can request hardware attested passkeys? In this case usb keyfob, or passkeys instanced from a secure enclave, etc.?
- Garrrrrr 1y ago
  stuff like this makes me wish Firefox supported serial communication like Chrome does :/. I haven't run into this since I don't have a hardware passkey, but the Circuit Python website makes it super easy to communicate and flash over serial... expect I have to use Chrome for five minutes
  - drdaeman 1y ago
    For DIY interaction with USB Webauthn/Passkey hardware tokens, you don't want serial (USB CDC), you want USB HID protocol. Those are two different things. This was briefly possible with WebUSB, but all mainstream browser vendors have a stoplist of certain USB devices for security reasons.
- tacticus 1y ago
  Just don't use that on windows with how they have broken most real hardware tokens with their bluetooth nonsense.
thescriptkiddie 1y ago
no they aren't, they are asymetric key pairs
- unethical_ban 1y ago
  They are static pieces of private data that require you to have a password manager. In simpleton terms, the title is accurate.
  - brookst 1y ago
    Can we substitute "password" for all instances of "private key"?
  - anonymars 1y ago
    Absolutely not, because the sensitive part (the private key) is never sent to the website, so unlike a password it cannot be sniffed or leaked or stolen. It will never end up in a data breach or haveibeenpwned. With this comes a new problem: how do you reset it?
    - unethical_ban 1y ago
      Good point. From a user perspective, though, the management of it remains, and in many cases, sites are not allowing you to manage your passkeys in your preferred manner. They become harder to back up and transfer.
486sx33 1y ago
[dead]
altmind 1y ago
Passkeys are the easiest way to lose access to your account.
- arresin 1y ago
  It’s no big deal. Just contact Google’s helpful customer service. I’m sure you’ll get a response.
  - ggm 1y ago
    If you have paid for google one, as I have, the help desk is real people and they are nice and responsive. I appreciate the corner case catch-22 "you need to be logged on to prove your status" but please, don't perpetuate the meme there is no google help desk. If you want google help desk, pay Google for support.
    - rurp 1y ago
      And you expect every one of Google's billion users to understand this distinction, and to be fully aware that services constantly marketed as Free actually need to be paid for?
      - ggm 1y ago
        No, thats also a mis-statement. Google gives away free, and google sells higher tiers. Google one is a higher tier. This is no different to any other provider of a service with a free tier. It's not marketed as "free" -It's marketed as the level above free. Things above free have to be paid for, they aren't marketed as free. A more reasonable, less argumentative response might be: "did you want them to offer helpdesk to free users" -which in fact, I did, until somebody pointed out the ARPU of a customer, and the cost of helpdesk (this is actually an anachronism, that was pointed out to me when I worked in a dial up ISP) -Whatever profit you extract from a low tier customer (of which free is the lowest tier) is very quickly eroded when you have to pay the staff who operate the helpdesk, and a customer calls in wanting helpdesk support.
    - 1y ago
shmerl 1y ago
They aren't passwords, they are just glorified private / public keys that are hard to manage due to all kind of attached requirements. But it's somewhat better now with tools like keepassxc.
- mminer237 1y ago
  Private keys themselves are essentially just glorified passwords.
  - droopyEyelids 1y ago
    I hope you are making a humorous understatement
  - Gigachad 1y ago
    It might help to think of them like that, but they aren't the same in some pretty important ways. The website never gets access to your private key like they do with passwords. So even if a website has it's database breached, there isn't a need to reset your passkeys since they were never compromised. I guess maybe you might have to be sure the attacker didn't replace your pub key with their own.
  - npteljes 1y ago
    Just in case you (or someone reading) doesn't know the technical details, private keys are distinctly different from passwords, on how they work to authenticate the user. In case of an online login, a password travels to the server, and gets checked against its stored form, to see if the user's login request is valid. In case of a private key, the server sends a bit of data that the user signs digitally on their own device with their private key, sends back the signed data, and the server checks authenticity with the user's previously stored public key. So at the end of the day, private keys are not essentially glorified passwords. Yes, both are strings that are used to authenticate. But it's their very essence itself that makes the difference.
drdaeman 1y ago
The article looks like either author knows something I don't (but fails to link any source on their claims), or is a bunch of misinformation. > Passkeys are randomly generated passwords that are required to be managed by a password manager. This is not correct. Passkeys are keypairs, and unlike shared secrets (like passwords) they do not require private key material to be ever revealed to the remote system. That's the whole point of Webauthn - so servers never ever possibly see any secret credentials. Otherwise - yes - they're random-looking blobs of data that is handled by a special software (which can be a password manager, but is not limited to password managers - e.g. an HSM like Yubikey can be used without any password management software), but that's where the similarity ends. > Passkeys can be public/private keypairs, or they can just be secret passwords. To best of my awareness, this is incorrect. I'm really curious where this idea comes from. In my understanding of the Webauthn spec it's all about public-key cryptography, attestations always use PublicKeyCredential. I'm not aware about any way to use a static token instead. Maybe it's possible to bastardize the standard somehow, but I doubt it's a real concern. > Password managers provide no way for you to copy and paste your passkeys. This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary. > A passkey manager is morally required to do an extra factor of authentication [...] but the site/app has no way of knowing/proving whether that happened This is partially correct. There is attestation in Webauthn, but to best of my awareness it's something frowned upon, so IMHO it's best if we all pretend it doesn't exist. If attestation is not required (which is AFAIK how most Webauthn-supporting services operate), it's up to user to decide on how they secure their system. And that's a good thing (YMMV), because it allows end user to have freedom of choice.
- moyix 1y ago
  There's also a FIDO standard in the works for how to export passkeys: https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk...
- reginald78 1y ago
  > This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary. This thread is one of the guys from FIDO threatening to blacklist keypass for doing just that, using the spec'd passkey attestation feature as the tool to do so. Just because the attestation feature isn't widely used as a weapon just this second doesn't mean that is not the intended endgame, in fact I'd argue the hand was tipped in that very thread.
ericpauley 1y ago
The design of passkeys is pretty solidly based around the idea that users are the weakest link the system and need to be protected from themselves. Given how criminally insecure passwords and push/code based MFA are in the face of user incompetence I have a hard time believing that WebAuthn is some grand plot by Big Tech to lock people into their walled gardens. I think people on HN overestimate the security literacy of the average computer user in a personal/corporate setting. If a sophisticated attacker wanted to target an organiztion with passwords/push auth, it'd be trivial to get some subset of members to copy-paste passwords from managers and accept prompts. I think far more likely than lock-in is that FIDO members genuinely want to make their customers more secure, something that passkeys very much do accomplish for the average user. That being said, I'm not rushing to enable passkeys on every site. If you already use a good password that enforces origin binding (the key strength of WebAuthn) and you extend that security perimeter through good OpSec (i.e., being careful when copy-pasting passwords), you're not getting much benefit.
- msgodel 1y ago
  >I think people on HN overestimate the security literacy of the average computer user in a personal/corporate setting. Sure. Provide an escape hatch for the technically literate and let us use our ssh-agent then.
  - ericpauley 1y ago
    Here's your escape hatch: https://bitwarden.com/help/export-your-data/ https://bitwarden.com/help/export-your-data/ Bitwarden even now supports passkeys on mobile browsers and apps. As a happy user for over 5 years it's been great being able to configure something less theatrical than push/codes without needing to plug in my YubiKey every time.
    - secabeen 1y ago
      Sadly, right now, bitwarden is the only provider that will dump your passkeys into a JSON. No one else offers it, and there is no functionality from any provider to import and adopt the JSON that bitwarden exports. Passwords have their faults, but they do have a zero-technology backup option that your heirs can execute. (A printed dump of the password vault in a locked fire safe.)
ecesena 1y ago
I don’t get the sentiment of the article. The whole point about passkeys is to replicate the exact UX of passwords (registration, reset…) but offer protection against phishing, by using public key crypto. If you want a different UX, use a hardware security key. But these failed to reach consumer adoption. And of course the FIDO2 standard didn’t specify (yet) a way to move passkeys around, so each implementation chose their own way to do vendor lock in. But this will be fixed in a few iterations.
- skybrian 1y ago
  I'm not sure why you're picking up negative sentiment? It seems mostly factual and not particularly against passkeys. (I'm in favor of passkeys, but also agree with the article that for people using password managers properly, there's no need to hurry on migrating.)
- dfabulich 1y ago
  Author here. My sentiment is mixed. I like the anti-phishing protection of passkeys. I don't like getting locked in to one password manager. I think passkeys are worth it for ordinary sites/apps that support resetting your password with a simple email, because if you lose your passkey, you can just reset your passkey with a simple email. The main point of the article is to demystify passkeys, especially passkey resets. Lots of people (especially on HN, even here on this thread) are in the habit of saying that if you lose your passkey, you're going to get permanently locked out of your account. That's no more true (and no less true) of passkeys than passwords. If you lose your password, you'll have to reset your password. If you lose your passkey, you'll have to reset your passkey, via the exact same process as resetting your password, however easy/hard that may be. Logging into Google with a passkey feels more perilous to me, especially if Google is your password manager. Losing your Google password is bad, but you can see your Google password. You can write it down and keep it somewhere secure in your house. If you're using a passkey to login to Google, you've really gotta go to https://myaccount.google.com/security https://myaccount.google.com/security and set up backup codes, and then keep those in a secure vault in your home. (But, if you can trust yourself to keep a secure backup code, and not give it away to a phisher, then you're not getting much benefit from passkeys, are you?)
eviks 1y ago
> Passkeys make it harder to switch password managers, because you can’t copy and paste them Does it not depend on the manager? Doesn't keepass manager allow open access to your passkey so you could also copy and paste it?
cedws 1y ago
My understanding of Passkeys used to be that they were hardware-bound, so stored in the system’s TPM, Secure Enclave, whatever. Somewhere they can’t be retrieved. As soon as I realised that wasn’t the case I lost all interest in Passkeys. Why would I bother when it’s basically just a password? Some services I’ve seen dangerously accept it as a form of 2FA, when it’s anything but.
- crote 1y ago
  That is the case - provided they are backed by a hardware token like a Yubikey.
  - timmyc123 1y ago
    This is correct. There are two types of passkeys: device-bound and synced. You can choose whichever credential manager/authenticator that supports your needs. https://passkeys.dev/docs/reference/terms/#synced-passkey https://passkeys.dev/docs/reference/terms/#synced-passkey https://passkeys.dev/docs/reference/terms/#device-bound-passkey https://passkeys.dev/docs/reference/terms/#device-bound-pass...
- Arrowmaster 1y ago
  One key difference is that it's not anything like a password. With a password, you send your password to the server and hope it's not intercepted or stored in plain text. Passkeys are more equivalent to the server sending you some random data and asking you to sign that data plus the server url with your private key. Then the server can check it against the public key it has to verify you possess the correct private key. It's both phishing and replay resistant.
conradev 1y ago
To present a passkey, you have to use a password manager. This provides some anti-phishing protection. Passkeys are locked to a domain, enforced by the browser. This completely breaks phishing. That's why we're doing this song and dance in the first place! You can't read a passkey over the phone or use it on the wrong website. The lock-in issue is more complex: - I write a VS Code extension for plain text passkey storage for simplicity. Do you allow servers to reject this? What should they reject? To oversimplify, the corporate folks argue for more control, the open source folks for less. - There is an exchange protocol in the works for data migration: https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.org/specifications-credential-exchange-...
- Ferret7446 1y ago
  > - I write a VS Code extension for plain text passkey storage for simplicity. Do you allow servers to reject this? What should they reject? To oversimplify, the corporate folks argue for more control, the open source folks for less. Irrelevant, servers can never control what clients do. The only way to control passkeys is using attestation CAs, which is insanely restrictive (not (just) for the users, but for the implementors), e.g., you only allow Yubikeys, Yubico provisions a TPM guarded endorsement key on the valid keys, and you send an additional challenge that must be signed by the endorsement key and validated by Yubico servers. This is completely, absolutely impractical outside of a closed org that supplies all of its own keys.
  - conradev 1y ago
    How is it "completely, absolutely impractical outside of a closed org" when I thought Google attests every passkey created on Android? https://www.w3.org/TR/webauthn-3/#sctn-android-key-attestation https://www.w3.org/TR/webauthn-3/#sctn-android-key-attestati... Apple would too, if it were not for iCloud Keychain syncing: https://news.ycombinator.com/item?id=43988852 https://news.ycombinator.com/item?id=43988852 My understanding is that servers can block passkeys from insecure Android devices today if they wanted to.
    - 1y ago
Incipient 1y ago
Having to centralise your, essentially login process, seems like an awful idea. Similarly to a paper ballot system, the current 'attack surface' of the huge array of password managers, text files, notebooks, etc renders compromising a specific someone's entire digital life not scalable really not so much a widespread thing. When every service is using a handful of central login handlers, I can imagine oppressive regimes, malicious entities, etc will have a field day trivially getting access to everything they've done and said. I'm not really a conspiracy theorist, but this definitely feels like it could go bad.
Kinrany 1y ago
The article already defeats itself in the title: password managers are a must-have. One needs to choose a good password manager, but that's already true.
dboreham 1y ago
This article is pretty much all wrong.
tolmasky 1y ago
It's telling that the "exchange protocol" was only begun to be developed after the main spec was written, and apparently as a response to pushback from the community. I can't imagine designing something like that and not having this be a core part of the feature set from day one. It's not even necessarily about switching vendors. When you first learn about passkeys, something as basic as what you need to do when you get a new computer is unclear. "The passwords are yours, we're just giving them a bodyguard" should have been the message from day one, but it wasn't of course, because that wasn't what was actually being pitched. I want to point out a subtle part of this critique: I don't necessarily think that vendor lock-in or anything like that was an intentional goal (I make no claim either way there), but rather what is worrying to me is that the experiences of the designers of this technology seem to be so different from ours that this feature wasn't an obvious v1 need, and as such makes me worried that the "solution" will also not be representative of what we actually need (perhaps it will be overly complicated and focus on the large vendors and not on being able to extract them easily yourself for example). This all sort of makes sense though, given that it seems to have had significant influence from humongous corporations like Apple and Google, where the idea of moving away sincerely confuses them. All of the "FIDO Alliance"[1] copy has a distinct tone of them seeing their job as chaperoning users like kids who don't know any better and are in constant danger of hurting themselves on the playground. Even the end user benefits read like business benefits on that site, with such gems as "Higher sign-in success rates". That made the list for convincing users? It's as if they've grown exasperated in trying to "teach" people about phishing, it feels like the obfuscation is a feature of passkeys, a long awaited release from the burden of learning about passwords. Which, to be clear, would possibly be great, if it handled the things people care about. But this obfuscation goes beyond the "implementation" and into the "usage". It goes from "it's simple to use" to "don't worry your pretty little head over that". I've found the whole thing rather bizarre, especially since many people on the browser side seem either oblivious to pushback, or annoyed. There is a unique "just trust us" feel to the this feature. A brief note: This isn't all that unexpected for completely non-nefarious reasons. I've spoken before about a common pattern I've witnessed where "platform owners" (where "owner" can be anything from a "company" to a "developer") usually start off empathizing with the user, but the longer they work on the platform, the more contempt they develop for the user and the more empathy they develop for "the platform". I've seen it everywhere from language and compiler developers (where the more senior they are, the more the features they suggest tend to make the "compiler's life" easier, such as complex features that enable performance boosts, instead of trying to figure out how to make the code people write go faster; to web engine developers, who over time suggest lower and lower level features (such as WebGPU or WASM) vs. "going big" on high level semantic features, etc.). This makes sense if you've ever worked in these environments, the nature of bug fixing and reporting is such that you get an incredibly lopsided biased view of the usage of the platform: you see all the worst usage of it. Day after day, it can demoralize and lead you to think that what users need is in fact to have less say in what goes on, your trust in their ability to learn or improve degrades, and with it "ergonomics" as a first priority. 1. https://fidoalliance.org/passkeys/ https://fidoalliance.org/passkeys/
marcus_holmes 1y ago
Yes. So?
dankwizard 1y ago
Holy AI slop Batman!
zarzavat 1y ago
Passkeys seem like alpha software that somehow got shipped by mistake. Wake me up in 5 years when/if they are actually safely usable (not just securely usable). Until then I advise my family members to stay away from them and I think everyone else should too.
- paul_h 1y ago
  Alpha and shipped too early - spot on. My personal strategy is to adopt at the last moment I absolutely have to. I know Dan, and liked the article, but I feel he ended it too early. The Passkeys leads don't have a solid website with an FAQ from a non-technical end user point of view and it is desperately needed.
thefz 1y ago
The difference is that I don't know my passkey by heart and can't give it away involuntarily. And the design of passkeys is way more robust than plain 2FA.
flowerthoughts 1y ago
> Passkeys can be public/private keypairs, or they can just be secret passwords. (WebAuthn passkeys were designed by committee, so there’s always more than one way to do it.) I'm surprised by this. Last time I checked, a few years ago, I couldn't create a passkey in Chrome without using either the Chrome developer tools to create an emulated passkey, or an actual hardware device. Why would I use a TPM to store a shared secret? Has this changed, or did I miss something? > Instead, password managers recommend that sites/apps allow each user to have multiple passkeys. Sites/apps may or may not actually allow that, but, for now, that’s the only way to be sure a given user can login with both Google’s password manager and Apple’s password manager: give each password manager its own passkey for each site. Having a simple procedure for rotating/replacing keys would probably be useful for the "switch password manager/TPM" case. I.e. a protocol between two password managers and a browser to do batch authorization of a new key. The migration story is one reason I don't use passkeys.
- eqvinox 1y ago
  > Why would I use a TPM to store a shared secret? I don't understand your incredulity at this; a disk encryption key is a shared secret and commonly stored in a TPM. It kinda still makes sense because the TPM 'enforces' platform security. But a TPM isn't the same as a hardware token, and storing a shared secret on a hardware token does make less sense. But that doesn't prevent people from doing it...
  - flowerthoughts 1y ago
    > a disk encryption key is a shared secret and commonly stored in a TPM. Thinking some more about this, you're right. If the stored shared secret is high entropy, and the user might choose a weak password, then using the TPM as a defense against password cracking is a useful reason for the seeming indirection. That assumes the TPM can e.g. rate limit extraction attempts and not be foiled by power-loss or sped up oscillators or similar externalities.
- timmyc123 1y ago
  > Why would I use a TPM to store a shared secret? There is no shared secret. A passkey is a public/private key pair.
xg15 1y ago
Fully admitting, I'm still learning about this topic. Also admitting that my current impression of the whole passkey system looks like a massively user-hostile and lock-in prone technology. But I have some questions to better understand it: - Suppose I'm a website owner and I handle authentication of my users with passkeys. Now for whatever reason, I want/have to move my site to a different domain. How would I "move" the passkeys, as they'd still be tied to the old domain? - Passkeys on Yubikeys or other dedicated hardware token sounds easy enough and mostly reasonable. (I could buy a bunch if yubikeys, copy the keys onto each of then and keep some if them as a backup in the drawer. The security properties of those seem a lot like regular keys or chip cards) Passkeys on phones or on cloud accounts much less so, but this is the main method that is promoted and expected to be used by "regular" users. But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored? - I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device?
- dfabulich 1y ago
  Let me address your questions in reverse order. > I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device? In general, logging into your password manager with a passkey is probably the least compelling way to use passkeys; you'll need some kinda backup code (i.e. a password) to avoid losing access to the password manager and the passkeys inside it. The company 1Password calls it that because, yes, you're probably going to need to memorize/retain one last password, the one you use to login to your password manager. If Google is your password manager, then, yeah, you're going to need something outside the password manager to login to the safe and get access to your passkeys and other passwords. You'll probably need to use a password for that. But https://myaccount.google.com/security https://myaccount.google.com/security lists a bunch of alternatives: • TOTP authenticator • Google prompt on multiple devices (login to YouTube on another machine? use that as a second factor) • Recovery email • Recovery phone • Backup codes (one-time passwords) If you lose your Google password, you'll have go through Google's password reset process. It can be hellish, but if you've set up backup codes and recovery contacts, you'll probably be fine. > But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored? Yeah, you lose access to your Google password/passkey safe when Google bans you. (It depends a little on how you got banned. If you're an identified persona non grata, sometimes they'll let you export some of your data with Google Takeout. If you're locked out of your account (because you lost your password and all of your other factors), well, of course you can't access your password safe at that point, because you can't prove your identity to Google.) If Google is your password safe, you really must set up backup codes, and you need to keep them safe. That's true regardless of whether you use Google passkeys or not. Either way, it sounds like maybe you don't want to trust Google as your password manager. It's perfectly reasonable to mistrust Google. There are a number of good alternative password managers that support passkeys; consider using them instead. > How would I "move" the passkeys, as they'd still be tied to the old domain? You can't really "move" passwords, either, because any phishing site could claim to be your site. ("We've moved! Please enter your password for example.com here. hehehe") But, while you control both sites, you could log people in on the old site and then redirect people over to your new site and let them create a new password/passkey there. But, if you're moving domains, you're probably just going to have to revalidate a significant fraction of your users, putting them through your "reset my password/passkey" flow. If your site does that with a "forgot my password" email, that's probably OK-ish.
Arnt 1y ago
I think the summary of that is "passkeys only solve the problems the designers cared to solve, and I care about some others but not those". I heard at a conference that users of one large freemail service store their passwords in an average of seven different files, so that provides an average of eight different possible attack vectors to get hold of a user's password — seven plus social engineering.

156 points by dfabulich 1y ago

JohnFen 1y ago

> To present a passkey, you have to use a password manager. This is what makes passkeys nonstarters for me.

aldshglkhdg 1y ago
that isn't true at all. i regularly use a yubikey as a passkey, and it's entirely orthogonal to any password manager i use. it happily just works on firefox on both mac and linux. to use a passkey, you need a place to store the passkey. that can be a hardware token, a tpm, or a password manager.
- deleted 1y ago
  [deleted]
- blindriver 1y ago
  What is someone steals your backpack with your laptop and all your yubikeys, your phone, etc? How do you get back your access?
  - dfedbeef 1y ago
    Don't keep all of your yubikeys and phones and laptops in one bag.
    - int_19h 1y ago
      Unfortunately, many services don't allow you to register multiple passkeys, so having a backup key that is stored somewhere safe is simply not an option.
      - chipsrafferty 1y ago
        That's why you have multiple passkeys that have the same key. It's a physical backup, not a software backup.
        crote 1y ago
        ... at which point you lose the whole "something you have" part of 2FA. If they all have the same key, it is impossible to distinguish between individual copies, so the compromise of a single copy is impossible to detect. Additionally, you can't revoke a single copy: you are now forced to revoke all of them at once.
        xg15 1y ago
        > Unfortunately, many services don't allow you to register multiple passkeys Doesn't this already make that scenario a nonstarter? I can't revoke individual keys if I can only register one key in the first place.
        esseph 1y ago
        You can revoke individual ones.
        rcxdude 1y ago
        Is that what you have set up? Can you describe how you do it in more detail? I'm looking for an option like this but everything I've found seems to suggest it's not possible (or at the very least wildly impractical). I'm looking for something where it's at least possible to make a physical backup that's still relatively secure.
      - dfedbeef 1y ago
        You only need multiple on your recovery email. Unless you're using Yahoo or running your own email server, this is an option.
        dfedbeef 1y ago
        It might be possible to set it up on a home server idk. I would rather waste my time on other stupid things.
    - blindriver 1y ago
      That doesn’t answer the question, unless it means you’re SOL. If that’s the case why on earth would I prefer passkeys to regular passwords as long as I practice safe password handling?
      - dfedbeef 1y ago
        Do whatever you want. It's easier for me to have a primary recovery email and password manager with MFA that uses a yubikey and phone authenticator. Then I can use passkeys or whatever for the rest of the stupid accounts that I don't care about. Side note: I feel like people always say 'i can just use good passwords' and then their password is like '<sports reference><year>'
  - chipsrafferty 1y ago
    Don't bring anythng you really wouldn't want to get stolen anywhere outside of your house.
    - blindriver 1y ago
      What if your house burns down with all your contents? My point being, there is a reasonable limit to how many physical passkeys a person would make but there’s also a non-zero possibility that a physical catastrophe could occur that destroys all the passkeys. What happens in that case? Can you recover your accounts?
      - tzs 1y ago
        Most sites currently have you create your account with a password, and then later you can add passkeys. If you still have your passwords after your house burns down you can use those to get into sites. If your house burning down also wiped out wherever you store your passwords, you'd use whatever mechanism each site provides for recovering from a lost password.
- JohnFen 1y ago
  Yubikeys are an even worse solution, in my opinion. They dramatically increase the amount of hassle and maintenance required because you have to have multiples of them to ensure that you won't get locked out. Also, it's not always convenient or possible to plug something into a machine you're using. > to use a passkey, you need a place to store the passkey. Yes, and any place that requires me to use particular piece of software, machine, or device is a real friction point for me.
dylan604 1y ago
Are you not already using password manager for all of your passwords? It took forever to make any movement towards getting people to stop using the same password every where. Now we're telling people passwords aren't secure even with using a password manager and they should use passkeys. So now we're saying that using the same software that we spent so much time suggesting to use is not good enough. Instead, now you want them to use a dedicated piece of hardware that needs to never be lost, but people lose their phones frequently. It's amazing to me how the majority of readers here absolutely cannot put themself in the place of non-computer nerds that spend 0% of their day thinking about code/security or anything other than what the Kardashiens are doing or their favorite influencer or whatever other nonsense that is everything and not nonsense to them. It's this kind of thinking that put us in this position that the people building the thing can't think about how the users will actually use it
- XorNot 1y ago
  That's not the problem: the problem is if I change password managers, or move software or any of many other possible things, whereas with password I can just type them into the new thing in the worst case...passkeys are wholly opaque. The ability to migrate them was considered an optional feature and not implemented before they were launched. It's still wholly unclear whether any individual implementation will let you do that or not, with options to prevent it.
  - dylan604 1y ago
    Again, it's us nerds making thing that didn't make it well enough that it causes pain on the end users. Not really sure how that's not the problem.
    - porridgeraisin 1y ago
      Standards/specs set incentives which uniquely decide implementation quality. If after many years implementations backed by a variety of funding and brains _all_ suck, then it's the standard/spec's problem.
- 1y ago
chipsrafferty 1y ago
It's not true at all. Not many apps support passkeys, but for the ones that do, it's a godsend. No longer do I have to worry about whether my password is stored in Google, or Firefox, or if it's up to date, or what happens if I get hacked. I just plug my little key into the computer and tap it. It's like having a physical key instead of having your password written in a page of an obscure book in the library. Probably safe, but someone dedicated can find it. A physical key can only be taken if my house gets robbed.
- eviks 1y ago
  > No longer do I have to worry about whether my password is stored in Google, or Firefox You never have too worry about it with a password manager, and also don't need to worry whether your key is plugged in in the computer you're currently using
- rcxdude 1y ago
  > No longer do I have to worry about whether my password is stored in Google, or Firefox Once Google and Firefox start pushing their passkey implementation, you do. One issue with them is user confusion about where the passkey is stored. And do you have a backup solution for if you lose your physical key? That's the big problem I have in practice at the moment: I would like a physical device for storing credentials, but I 100% cannot have it as a single point of failure. Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them!.
  - tzs 1y ago
    > Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them! • You can use multiple independent cloud sync vendors. When I add passkeys to an account I add two passkeys. One gets stored in 1Password and synced using their cloud. The other gets stored in Apple's Password and synced using Apple's cloud. This should give you enough redundancy to mitigate most vendor lock-in concerns. • If using devices that don't cloud sync I don't see why your would need to carry around two devices in order to enroll two devices. Carry around one device, and when you make a new account create a passkey for that account stored in the device. Later, back home, login into any accounts you created while away using the passkeys on the device you were carrying, and create a second passkey on each of those accounts and store it on the other device.
esseph 1y ago
How do you plan to sync your passkey between devices? Another feature of the password manager.

lazzlazzlazz 1y ago

The fact that you can't actually see the passkey is absurd. I understand it's a "feature" prevent phishing — victims have a lot less to share — but it constrains more sophisticated storage and use of passwords.

shmerl 1y ago
Their spec doesn't dictate that you shouldn't be able to see it. It's just dumb implementations that do it (mostly for lock-in purposes). There are ones where you can see it just fine.
- Gigachad 1y ago
  It's not for lock in, it's for anti phishing purposes. Passkey managers are designed so that grandma on the phone to a scammer can't physically dump and email her entire passkey vault. It's impossible to get phished by a fake login page with Passkeys and it's impossible to send your private keys to someone on the mainstream Passkey managers. Portability between Passkey managers is still an issue though. Last I checked there were in draft specs for migrating between managers but nothing ready yet.
  - shmerl 1y ago
    Not being able to see it all can't be justified with "for phishing purposes". You can put a big warning there that exposing your private key is a risk, but user should be able to see it with needed effort. Not being able to see it at all is a problem, like anything that moves away control from the user to some external entity. Of course they'll happily justify it with security reasons, but that doesn't remove the problem.
    - Gigachad 1y ago
      The person on the phone will just instruct grandma to ignore the warning and that it's important she continue and send the private key over to secure her account. Considering there isn't really anything you can do with the private key other than logging in to a website, making phishing impossible is a higher priority than letting people view the keys. There are alternative open source passkey managers which do let you view them. But it seems pretty obvious the average person is much better off not having this.

Darkskiez 1y ago

Except you can store the passwords on a usb key / remote over bluetooth, and then also keep them secret from the potentially compromised host.

gnabgib 1y ago
The first passkeys were physical (USB) keys. And you never share the key with a host or server.

commandersaki 1y ago

A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login, but the site/app has no way of knowing/proving whether that happened; they just get the password. Thought sites can request hardware attested passkeys? In this case usb keyfob, or passkeys instanced from a secure enclave, etc.?

Garrrrrr 1y ago
stuff like this makes me wish Firefox supported serial communication like Chrome does :/. I haven't run into this since I don't have a hardware passkey, but the Circuit Python website makes it super easy to communicate and flash over serial... expect I have to use Chrome for five minutes
- drdaeman 1y ago
  For DIY interaction with USB Webauthn/Passkey hardware tokens, you don't want serial (USB CDC), you want USB HID protocol. Those are two different things. This was briefly possible with WebUSB, but all mainstream browser vendors have a stoplist of certain USB devices for security reasons.
tacticus 1y ago
Just don't use that on windows with how they have broken most real hardware tokens with their bluetooth nonsense.

thescriptkiddie 1y ago

no they aren't, they are asymetric key pairs

unethical_ban 1y ago
They are static pieces of private data that require you to have a password manager. In simpleton terms, the title is accurate.
- brookst 1y ago
  Can we substitute "password" for all instances of "private key"?
- anonymars 1y ago
  Absolutely not, because the sensitive part (the private key) is never sent to the website, so unlike a password it cannot be sniffed or leaked or stolen. It will never end up in a data breach or haveibeenpwned. With this comes a new problem: how do you reset it?
  - unethical_ban 1y ago
    Good point. From a user perspective, though, the management of it remains, and in many cases, sites are not allowing you to manage your passkeys in your preferred manner. They become harder to back up and transfer.

486sx33 1y ago

[dead]

altmind 1y ago

Passkeys are the easiest way to lose access to your account.

arresin 1y ago
It’s no big deal. Just contact Google’s helpful customer service. I’m sure you’ll get a response.
- ggm 1y ago
  If you have paid for google one, as I have, the help desk is real people and they are nice and responsive. I appreciate the corner case catch-22 "you need to be logged on to prove your status" but please, don't perpetuate the meme there is no google help desk. If you want google help desk, pay Google for support.
  - rurp 1y ago
    And you expect every one of Google's billion users to understand this distinction, and to be fully aware that services constantly marketed as Free actually need to be paid for?
    - ggm 1y ago
      No, thats also a mis-statement. Google gives away free, and google sells higher tiers. Google one is a higher tier. This is no different to any other provider of a service with a free tier. It's not marketed as "free" -It's marketed as the level above free. Things above free have to be paid for, they aren't marketed as free. A more reasonable, less argumentative response might be: "did you want them to offer helpdesk to free users" -which in fact, I did, until somebody pointed out the ARPU of a customer, and the cost of helpdesk (this is actually an anachronism, that was pointed out to me when I worked in a dial up ISP) -Whatever profit you extract from a low tier customer (of which free is the lowest tier) is very quickly eroded when you have to pay the staff who operate the helpdesk, and a customer calls in wanting helpdesk support.
  - 1y ago

shmerl 1y ago

They aren't passwords, they are just glorified private / public keys that are hard to manage due to all kind of attached requirements. But it's somewhat better now with tools like keepassxc.

mminer237 1y ago
Private keys themselves are essentially just glorified passwords.
- droopyEyelids 1y ago
  I hope you are making a humorous understatement
- Gigachad 1y ago
  It might help to think of them like that, but they aren't the same in some pretty important ways. The website never gets access to your private key like they do with passwords. So even if a website has it's database breached, there isn't a need to reset your passkeys since they were never compromised. I guess maybe you might have to be sure the attacker didn't replace your pub key with their own.
- npteljes 1y ago
  Just in case you (or someone reading) doesn't know the technical details, private keys are distinctly different from passwords, on how they work to authenticate the user. In case of an online login, a password travels to the server, and gets checked against its stored form, to see if the user's login request is valid. In case of a private key, the server sends a bit of data that the user signs digitally on their own device with their private key, sends back the signed data, and the server checks authenticity with the user's previously stored public key. So at the end of the day, private keys are not essentially glorified passwords. Yes, both are strings that are used to authenticate. But it's their very essence itself that makes the difference.

drdaeman 1y ago

The article looks like either author knows something I don't (but fails to link any source on their claims), or is a bunch of misinformation. > Passkeys are randomly generated passwords that are required to be managed by a password manager. This is not correct. Passkeys are keypairs, and unlike shared secrets (like passwords) they do not require private key material to be ever revealed to the remote system. That's the whole point of Webauthn - so servers never ever possibly see any secret credentials. Otherwise - yes - they're random-looking blobs of data that is handled by a special software (which can be a password manager, but is not limited to password managers - e.g. an HSM like Yubikey can be used without any password management software), but that's where the similarity ends. > Passkeys can be public/private keypairs, or they can just be secret passwords. To best of my awareness, this is incorrect. I'm really curious where this idea comes from. In my understanding of the Webauthn spec it's all about public-key cryptography, attestations always use PublicKeyCredential. I'm not aware about any way to use a static token instead. Maybe it's possible to bastardize the standard somehow, but I doubt it's a real concern. > Password managers provide no way for you to copy and paste your passkeys. This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary. > A passkey manager is morally required to do an extra factor of authentication [...] but the site/app has no way of knowing/proving whether that happened This is partially correct. There is attestation in Webauthn, but to best of my awareness it's something frowned upon, so IMHO it's best if we all pretend it doesn't exist. If attestation is not required (which is AFAIK how most Webauthn-supporting services operate), it's up to user to decide on how they secure their system. And that's a good thing (YMMV), because it allows end user to have freedom of choice.

moyix 1y ago
There's also a FIDO standard in the works for how to export passkeys: https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/ https://blog.1password.com/fido-alliance-import-export-passk...
reginald78 1y ago
> This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary. This thread is one of the guys from FIDO threatening to blacklist keypass for doing just that, using the spec'd passkey attestation feature as the tool to do so. Just because the attestation feature isn't widely used as a weapon just this second doesn't mean that is not the intended endgame, in fact I'd argue the hand was tipped in that very thread.

ericpauley 1y ago

The design of passkeys is pretty solidly based around the idea that users are the weakest link the system and need to be protected from themselves. Given how criminally insecure passwords and push/code based MFA are in the face of user incompetence I have a hard time believing that WebAuthn is some grand plot by Big Tech to lock people into their walled gardens. I think people on HN overestimate the security literacy of the average computer user in a personal/corporate setting. If a sophisticated attacker wanted to target an organiztion with passwords/push auth, it'd be trivial to get some subset of members to copy-paste passwords from managers and accept prompts. I think far more likely than lock-in is that FIDO members genuinely want to make their customers more secure, something that passkeys very much do accomplish for the average user. That being said, I'm not rushing to enable passkeys on every site. If you already use a good password that enforces origin binding (the key strength of WebAuthn) and you extend that security perimeter through good OpSec (i.e., being careful when copy-pasting passwords), you're not getting much benefit.

msgodel 1y ago
>I think people on HN overestimate the security literacy of the average computer user in a personal/corporate setting. Sure. Provide an escape hatch for the technically literate and let us use our ssh-agent then.
- ericpauley 1y ago
  Here's your escape hatch: https://bitwarden.com/help/export-your-data/ https://bitwarden.com/help/export-your-data/ Bitwarden even now supports passkeys on mobile browsers and apps. As a happy user for over 5 years it's been great being able to configure something less theatrical than push/codes without needing to plug in my YubiKey every time.
  - secabeen 1y ago
    Sadly, right now, bitwarden is the only provider that will dump your passkeys into a JSON. No one else offers it, and there is no functionality from any provider to import and adopt the JSON that bitwarden exports. Passwords have their faults, but they do have a zero-technology backup option that your heirs can execute. (A printed dump of the password vault in a locked fire safe.)

ecesena 1y ago

I don’t get the sentiment of the article. The whole point about passkeys is to replicate the exact UX of passwords (registration, reset…) but offer protection against phishing, by using public key crypto. If you want a different UX, use a hardware security key. But these failed to reach consumer adoption. And of course the FIDO2 standard didn’t specify (yet) a way to move passkeys around, so each implementation chose their own way to do vendor lock in. But this will be fixed in a few iterations.

skybrian 1y ago
I'm not sure why you're picking up negative sentiment? It seems mostly factual and not particularly against passkeys. (I'm in favor of passkeys, but also agree with the article that for people using password managers properly, there's no need to hurry on migrating.)
dfabulich 1y ago
Author here. My sentiment is mixed. I like the anti-phishing protection of passkeys. I don't like getting locked in to one password manager. I think passkeys are worth it for ordinary sites/apps that support resetting your password with a simple email, because if you lose your passkey, you can just reset your passkey with a simple email. The main point of the article is to demystify passkeys, especially passkey resets. Lots of people (especially on HN, even here on this thread) are in the habit of saying that if you lose your passkey, you're going to get permanently locked out of your account. That's no more true (and no less true) of passkeys than passwords. If you lose your password, you'll have to reset your password. If you lose your passkey, you'll have to reset your passkey, via the exact same process as resetting your password, however easy/hard that may be. Logging into Google with a passkey feels more perilous to me, especially if Google is your password manager. Losing your Google password is bad, but you can see your Google password. You can write it down and keep it somewhere secure in your house. If you're using a passkey to login to Google, you've really gotta go to https://myaccount.google.com/security https://myaccount.google.com/security and set up backup codes, and then keep those in a secure vault in your home. (But, if you can trust yourself to keep a secure backup code, and not give it away to a phisher, then you're not getting much benefit from passkeys, are you?)

eviks 1y ago

> Passkeys make it harder to switch password managers, because you can’t copy and paste them Does it not depend on the manager? Doesn't keepass manager allow open access to your passkey so you could also copy and paste it?

cedws 1y ago

My understanding of Passkeys used to be that they were hardware-bound, so stored in the system’s TPM, Secure Enclave, whatever. Somewhere they can’t be retrieved. As soon as I realised that wasn’t the case I lost all interest in Passkeys. Why would I bother when it’s basically just a password? Some services I’ve seen dangerously accept it as a form of 2FA, when it’s anything but.

crote 1y ago
That is the case - provided they are backed by a hardware token like a Yubikey.
- timmyc123 1y ago
  This is correct. There are two types of passkeys: device-bound and synced. You can choose whichever credential manager/authenticator that supports your needs. https://passkeys.dev/docs/reference/terms/#synced-passkey https://passkeys.dev/docs/reference/terms/#synced-passkey https://passkeys.dev/docs/reference/terms/#device-bound-passkey https://passkeys.dev/docs/reference/terms/#device-bound-pass...
Arrowmaster 1y ago
One key difference is that it's not anything like a password. With a password, you send your password to the server and hope it's not intercepted or stored in plain text. Passkeys are more equivalent to the server sending you some random data and asking you to sign that data plus the server url with your private key. Then the server can check it against the public key it has to verify you possess the correct private key. It's both phishing and replay resistant.

conradev 1y ago

To present a passkey, you have to use a password manager. This provides some anti-phishing protection. Passkeys are locked to a domain, enforced by the browser. This completely breaks phishing. That's why we're doing this song and dance in the first place! You can't read a passkey over the phone or use it on the wrong website. The lock-in issue is more complex: - I write a VS Code extension for plain text passkey storage for simplicity. Do you allow servers to reject this? What should they reject? To oversimplify, the corporate folks argue for more control, the open source folks for less. - There is an exchange protocol in the works for data migration: https://fidoalliance.org/specifications-credential-exchange-specifications/ https://fidoalliance.org/specifications-credential-exchange-...

Ferret7446 1y ago
> - I write a VS Code extension for plain text passkey storage for simplicity. Do you allow servers to reject this? What should they reject? To oversimplify, the corporate folks argue for more control, the open source folks for less. Irrelevant, servers can never control what clients do. The only way to control passkeys is using attestation CAs, which is insanely restrictive (not (just) for the users, but for the implementors), e.g., you only allow Yubikeys, Yubico provisions a TPM guarded endorsement key on the valid keys, and you send an additional challenge that must be signed by the endorsement key and validated by Yubico servers. This is completely, absolutely impractical outside of a closed org that supplies all of its own keys.
- conradev 1y ago
  How is it "completely, absolutely impractical outside of a closed org" when I thought Google attests every passkey created on Android? https://www.w3.org/TR/webauthn-3/#sctn-android-key-attestation https://www.w3.org/TR/webauthn-3/#sctn-android-key-attestati... Apple would too, if it were not for iCloud Keychain syncing: https://news.ycombinator.com/item?id=43988852 https://news.ycombinator.com/item?id=43988852 My understanding is that servers can block passkeys from insecure Android devices today if they wanted to.
  - 1y ago

Incipient 1y ago

Having to centralise your, essentially login process, seems like an awful idea. Similarly to a paper ballot system, the current 'attack surface' of the huge array of password managers, text files, notebooks, etc renders compromising a specific someone's entire digital life not scalable really not so much a widespread thing. When every service is using a handful of central login handlers, I can imagine oppressive regimes, malicious entities, etc will have a field day trivially getting access to everything they've done and said. I'm not really a conspiracy theorist, but this definitely feels like it could go bad.

Kinrany 1y ago

The article already defeats itself in the title: password managers are a must-have. One needs to choose a good password manager, but that's already true.

dboreham 1y ago

This article is pretty much all wrong.

tolmasky 1y ago

It's telling that the "exchange protocol" was only begun to be developed after the main spec was written, and apparently as a response to pushback from the community. I can't imagine designing something like that and not having this be a core part of the feature set from day one. It's not even necessarily about switching vendors. When you first learn about passkeys, something as basic as what you need to do when you get a new computer is unclear. "The passwords are yours, we're just giving them a bodyguard" should have been the message from day one, but it wasn't of course, because that wasn't what was actually being pitched. I want to point out a subtle part of this critique: I don't necessarily think that vendor lock-in or anything like that was an intentional goal (I make no claim either way there), but rather what is worrying to me is that the experiences of the designers of this technology seem to be so different from ours that this feature wasn't an obvious v1 need, and as such makes me worried that the "solution" will also not be representative of what we actually need (perhaps it will be overly complicated and focus on the large vendors and not on being able to extract them easily yourself for example). This all sort of makes sense though, given that it seems to have had significant influence from humongous corporations like Apple and Google, where the idea of moving away sincerely confuses them. All of the "FIDO Alliance"[1] copy has a distinct tone of them seeing their job as chaperoning users like kids who don't know any better and are in constant danger of hurting themselves on the playground. Even the end user benefits read like business benefits on that site, with such gems as "Higher sign-in success rates". That made the list for convincing users? It's as if they've grown exasperated in trying to "teach" people about phishing, it feels like the obfuscation is a feature of passkeys, a long awaited release from the burden of learning about passwords. Which, to be clear, would possibly be great, if it handled the things people care about. But this obfuscation goes beyond the "implementation" and into the "usage". It goes from "it's simple to use" to "don't worry your pretty little head over that". I've found the whole thing rather bizarre, especially since many people on the browser side seem either oblivious to pushback, or annoyed. There is a unique "just trust us" feel to the this feature. A brief note: This isn't all that unexpected for completely non-nefarious reasons. I've spoken before about a common pattern I've witnessed where "platform owners" (where "owner" can be anything from a "company" to a "developer") usually start off empathizing with the user, but the longer they work on the platform, the more contempt they develop for the user and the more empathy they develop for "the platform". I've seen it everywhere from language and compiler developers (where the more senior they are, the more the features they suggest tend to make the "compiler's life" easier, such as complex features that enable performance boosts, instead of trying to figure out how to make the code people write go faster; to web engine developers, who over time suggest lower and lower level features (such as WebGPU or WASM) vs. "going big" on high level semantic features, etc.). This makes sense if you've ever worked in these environments, the nature of bug fixing and reporting is such that you get an incredibly lopsided biased view of the usage of the platform: you see all the worst usage of it. Day after day, it can demoralize and lead you to think that what users need is in fact to have less say in what goes on, your trust in their ability to learn or improve degrades, and with it "ergonomics" as a first priority. 1. https://fidoalliance.org/passkeys/ https://fidoalliance.org/passkeys/

marcus_holmes 1y ago

Yes. So?

dankwizard 1y ago

Holy AI slop Batman!

zarzavat 1y ago

Passkeys seem like alpha software that somehow got shipped by mistake. Wake me up in 5 years when/if they are actually safely usable (not just securely usable). Until then I advise my family members to stay away from them and I think everyone else should too.

paul_h 1y ago
Alpha and shipped too early - spot on. My personal strategy is to adopt at the last moment I absolutely have to. I know Dan, and liked the article, but I feel he ended it too early. The Passkeys leads don't have a solid website with an FAQ from a non-technical end user point of view and it is desperately needed.

thefz 1y ago

The difference is that I don't know my passkey by heart and can't give it away involuntarily. And the design of passkeys is way more robust than plain 2FA.

flowerthoughts 1y ago

> Passkeys can be public/private keypairs, or they can just be secret passwords. (WebAuthn passkeys were designed by committee, so there’s always more than one way to do it.) I'm surprised by this. Last time I checked, a few years ago, I couldn't create a passkey in Chrome without using either the Chrome developer tools to create an emulated passkey, or an actual hardware device. Why would I use a TPM to store a shared secret? Has this changed, or did I miss something? > Instead, password managers recommend that sites/apps allow each user to have multiple passkeys. Sites/apps may or may not actually allow that, but, for now, that’s the only way to be sure a given user can login with both Google’s password manager and Apple’s password manager: give each password manager its own passkey for each site. Having a simple procedure for rotating/replacing keys would probably be useful for the "switch password manager/TPM" case. I.e. a protocol between two password managers and a browser to do batch authorization of a new key. The migration story is one reason I don't use passkeys.

eqvinox 1y ago
> Why would I use a TPM to store a shared secret? I don't understand your incredulity at this; a disk encryption key is a shared secret and commonly stored in a TPM. It kinda still makes sense because the TPM 'enforces' platform security. But a TPM isn't the same as a hardware token, and storing a shared secret on a hardware token does make less sense. But that doesn't prevent people from doing it...
- flowerthoughts 1y ago
  > a disk encryption key is a shared secret and commonly stored in a TPM. Thinking some more about this, you're right. If the stored shared secret is high entropy, and the user might choose a weak password, then using the TPM as a defense against password cracking is a useful reason for the seeming indirection. That assumes the TPM can e.g. rate limit extraction attempts and not be foiled by power-loss or sped up oscillators or similar externalities.
timmyc123 1y ago
> Why would I use a TPM to store a shared secret? There is no shared secret. A passkey is a public/private key pair.

xg15 1y ago

Fully admitting, I'm still learning about this topic. Also admitting that my current impression of the whole passkey system looks like a massively user-hostile and lock-in prone technology. But I have some questions to better understand it: - Suppose I'm a website owner and I handle authentication of my users with passkeys. Now for whatever reason, I want/have to move my site to a different domain. How would I "move" the passkeys, as they'd still be tied to the old domain? - Passkeys on Yubikeys or other dedicated hardware token sounds easy enough and mostly reasonable. (I could buy a bunch if yubikeys, copy the keys onto each of then and keep some if them as a backup in the drawer. The security properties of those seem a lot like regular keys or chip cards) Passkeys on phones or on cloud accounts much less so, but this is the main method that is promoted and expected to be used by "regular" users. But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored? - I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device?

dfabulich 1y ago
Let me address your questions in reverse order. > I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device? In general, logging into your password manager with a passkey is probably the least compelling way to use passkeys; you'll need some kinda backup code (i.e. a password) to avoid losing access to the password manager and the passkeys inside it. The company 1Password calls it that because, yes, you're probably going to need to memorize/retain one last password, the one you use to login to your password manager. If Google is your password manager, then, yeah, you're going to need something outside the password manager to login to the safe and get access to your passkeys and other passwords. You'll probably need to use a password for that. But https://myaccount.google.com/security https://myaccount.google.com/security lists a bunch of alternatives: • TOTP authenticator • Google prompt on multiple devices (login to YouTube on another machine? use that as a second factor) • Recovery email • Recovery phone • Backup codes (one-time passwords) If you lose your Google password, you'll have go through Google's password reset process. It can be hellish, but if you've set up backup codes and recovery contacts, you'll probably be fine. > But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored? Yeah, you lose access to your Google password/passkey safe when Google bans you. (It depends a little on how you got banned. If you're an identified persona non grata, sometimes they'll let you export some of your data with Google Takeout. If you're locked out of your account (because you lost your password and all of your other factors), well, of course you can't access your password safe at that point, because you can't prove your identity to Google.) If Google is your password safe, you really must set up backup codes, and you need to keep them safe. That's true regardless of whether you use Google passkeys or not. Either way, it sounds like maybe you don't want to trust Google as your password manager. It's perfectly reasonable to mistrust Google. There are a number of good alternative password managers that support passkeys; consider using them instead. > How would I "move" the passkeys, as they'd still be tied to the old domain? You can't really "move" passwords, either, because any phishing site could claim to be your site. ("We've moved! Please enter your password for example.com here. hehehe") But, while you control both sites, you could log people in on the old site and then redirect people over to your new site and let them create a new password/passkey there. But, if you're moving domains, you're probably just going to have to revalidate a significant fraction of your users, putting them through your "reset my password/passkey" flow. If your site does that with a "forgot my password" email, that's probably OK-ish.

Arnt 1y ago

I think the summary of that is "passkeys only solve the problems the designers cared to solve, and I care about some others but not those". I heard at a conference that users of one large freemail service store their passwords in an average of seven different files, so that provides an average of eight different possible attack vectors to get hold of a user's password — seven plus social engineering.