30 ms·

Passkey Implementation: Misconceptions, pitfalls and unknown unknowns

184 points by vdelitz 2y ago

okhuman 2y ago
I have a nodejs passkey implementation over at AuthC https://github.com/authcompanion/authcompanion2 https://github.com/authcompanion/authcompanion2 a simple user management server. For javascript developers https://github.com/MasterKale/SimpleWebAuthn https://github.com/MasterKale/SimpleWebAuthn has been a good way to get started with a poc before venturing deeper into webauthn (passkeys) spec.
grose 2y ago
Very thorough article, nice! I'll add some other pain points I experienced: - You need to let users register more than 1 passkey, but how to show them which is which? There are lists like this one[1] and FIDO provides a (maybe irrelevant?) list on their site[2] stuck inside of a JWT. I ended up using that JSON list + registration date + browser UA that registered it + "currently using" indicator when the current session derives from that specific passkey. Still kind of feels like a mess. - The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64, which doesn't have native browser support. Not a big deal (just a couple helper functions needed) but kind of confusing if you're trying to implement the client or server bits from scratch. [Edit: as explained by a reply below, this is part of the actual spec!] - I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. The APIs seem to be mutually exclusive, differentiated by some options (some of which are already deprecated?) and requiring empty lists to be passed in certain places. I'm trying to bolt on passkeys to a pre-existing auth flow and all I want is the closest thing to "use the browser's built in password manager". Ended up giving up on resident keys for now. [1]: https://github.com/passkeydeveloper/passkey-authenticator-aaguids/blob/main/aaguid.json https://github.com/passkeydeveloper/passkey-authenticator-aa... [2]: https://fidoalliance.org/metadata/ https://fidoalliance.org/metadata/
- toomuchtodo 2y ago
  Do you allow users to rename their passkeys in your user interface? I very much like how GitHub handles this, take a look in that view if you have a GitHub account. You also get nice info like "Seen from this browser" and "Synced" (non device bound passkeys) indicators if applicable. https://github.com/settings/security https://github.com/settings/security (Passkeys section) https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys https://docs.github.com/en/authentication/authenticating-wit...
  - grose 2y ago
    That's a good idea, thanks for the suggestion! Maybe I'll let them rename the keys with the provider as the default name. Haven't played with GitHub's implementation yet but I'll play around with it.
- agl 2y ago
  > The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64 WebAuthn itself uses base64url rather than base64. See, e.g., the `id` field here: https://www.w3.org/TR/webauthn-2/#iface-pkcredential https://www.w3.org/TR/webauthn-2/#iface-pkcredential (It was probably a mistake, but it predates me so I don't know the motivation.) > I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. Non-discoverable credentials can only be used if their credential ID is passed in an allowlist. Discoverable credentials (a.k.a. "resident" in the API, although that name is a bit misleading) _can_ be enumerated in an allowlist. So they can work together, but to have the allowlist you must collect a username first or have some other way of know which account is pertinent to the current session.
  - grose 2y ago
    Aha, so it is part of the spec. Thanks for clarifying that. Appreciate the advice on discoverable credentials as well! I was probably leaving out the discoverable creds from the allowlist. Getting the timing down for when to ask for credentials was a bit tricky but I think I see the whole picture now. I will say though, when it all works out it's a really nice way to log in, and my users are happy about it.
- foxylad 2y ago
  We ask the user to name each passkey. One more modal dialog during registration, but seems to work well.
tptacek 2y ago
Two assumptions I have, and I'd love for people to shoot me down on this: 1. Most applications will get "Passkey" support by dint of OIDC SSO support; OIDC IdPs are the things that will implement Passkeys (SIWA and SIWG for "retail" users). 2. Direct Passkey adoption in applications will round towards zero, maybe excepting huge applications like Insta; people will do Passkeys with their Google account, but not with (say) Doordash. If those premises hold, I probably don't need to be sold (though this post is helpful and incredibly detailed) on why not to do my own direct implementation of Passkeys; it makes more sense for us to nail OIDC.
- simonw 2y ago
  What you're saying mostly makes sense to me, but there's one big edge-case that I care about. For my own applications I like to have my staff-level admin access work independently of external providers. I don't want to run into a situation where my Google account (or some other SSO service) has been accidentally banned by a weird machine learning algorithm hiccup and now I can't sign into my own service's dashboard to sort out problems. Admin accounts are also exactly the kind of thing that I want to have my own 2FA for - so passkeys are ideal for them. So yeah, Passkeys for retail users is something I'll outsource to an IdP, but I'm still very interested in them for my own "staff-level" administrative accounts.
  - kemotep 2y ago
    Yeah that’s a break glass account situation. Even with a self hosted IdP solution, it going down isn’t going to perform the OIDC SSO dance to get into whatever service so having that backup account or fallback authentication access is important.
- johngalt 2y ago
  100% That is exactly how it is playing out. People do not register (2passkeys * 20 services). They sign in with Google or Microsoft and call it a day. Privacy implications ignored. Even more true in Corp IT. People will learn to use passkeys with SSO at the office and take those habits home.
deleted 2y ago
[deleted]
snailmailman 2y ago
I still haven’t really migrated to passkeys yet. Until Bitwarden on iOS properly supports them I won’t fully switch. I don’t want to have to manage a passkey on every device. So I will wait until I can sync between all my devices. But when I did play with them a bit it seemed so full of weird pitfalls. Aren’t I supposed to be able to use my phones passkey to login on my PC with a QR code? I never got that to work. The article implies that might be a windows 10 vs 11 issue- but why? It’s a QR code. Windows 10 should be capable of displaying a QR code. I tried it just now. Windows pulls up a “making sure it’s you” box, with no buttons other than cancel, and no option to use the passkey from elsewhere. This computer doesn’t have a passkey, what is windows doing?
- pat2man 2y ago
  There is a Bluetooth part of the spec too. If your phone can’t talk to your computer via Bluetooth it won’t work.
  - deleted 2y ago
    [deleted]
- jeroenhd 2y ago
  QR codes are usually the fallback method, I believe, because they're clunky and they suck if you need to do it more than once per week. Laptops and phones use Bluetooth Low Energy (among others) to communicate (CTAP 2.2) which is what your computer may be waiting on. I can't tell you why you couldn't log in, I use Bitwarden's passkeys and they work reliably for me. If you want the added security your phone's hardware encryption provides, I believe there are a few annoyances, particularly with the way Android 13 and lower, but I haven't had to look into those yet.
zie 2y ago
tldr; It's still a giant mess, and until browser developers get around to fixing it, it's probably better to punt on Passkeys for now. The question is, can the mess get fixed enough before developers like me give up and move on to something else. I gave up a while ago, figured I'd check back in a few years. My current guess: I'll never have to implement them.
- jillesvangurp 2y ago
  That's my current impression as well. The companies involved are more interested in making themselves the center of the universe than in collaborating to address the rather obvious user and developer experience issues. Nobody seems in a hurry to do this. It's the same reason why previous attempts at federated identity have fizzled out. Both MS and Google loved the idea of the whole world using them exclusively as the only identity provider but then balked at the notion of their users using an identity provider that wasn't them. Passkey is a repeat of this. Apple loves the idea of people using iphones to identify with whatever. Android, not so much. And MS of course wants to keep a tight grip on passkey's used to sign into Office, Windows, etc.
- p0seidon 2y ago
  Disclaimer: Co-Founder Corbado here. I think the simplicity actually for the user is why they are so successful already. I can understand a lot of the criticism, although I am not that skeptical regarding the lock-in. I think this discussion is probably already lost with most consumers having their life within Google or Apple cloud via the mobile phone. Although the discussion is valuable, it should not be held over passkeys. For passkeys, we truly believe even if those options are weighed against each other, the benefits are weighing more. Big consumer-facing platforms have huge problems securing accounts for users. If you force them to use classic MFA (SMS or TOTP), the usage drops and recovery/fallback processes skyrocket. They don't want MFA. Risk-based MFA can help but is not perfect as attacks get more precise. So we think the adoption will be faster than browser developers can get around fixing all of the issues, because once a standard is adopted, it gets more and more difficult to streamline things. But we are looking forward to it. Of course, we see it that way, because we are building a company around it, but I have been battling against account takeover for years and took great pride in trying to protect the data as a developer, our users entrusted us. So I see a real chance here to improve security in the consumer market.
CatWChainsaw 2y ago
About three weeks ago, I grabbed some samples out of a freezer at -80C without gloves because it was quick. Yes it was stupid! (It's also quite common that someone who needs to "grab one sample real quick" does this.) The fingers on my right hand felt prickly for a couple minutes after that but no harm, it seemed. Well it took a couple weeks but the fingertips on my right hand all started blistering and one finger basically has a second-degree burn. My left hand, which I didn't use on the freezer, seems to be experiencing mirroring blisters, and I have no explanation since I didn't do anything (stupid or otherwise) to burn/blister them. If I were relying on passkeys and I couldn't register multiple keys, like one for each of my ten fingers plus face plus hardware token, I'd be locked out of my passkey-protected accounts for... I mean I honestly don't know how long, my fingerprints could still be healing a month from now. So between that and the kinks that still need to be worked out regarding exporting and FAANG lock-in, I'll keep using my passwords. And wearing gloves when using -80C freezers.
- shepherdjerred 2y ago
  Passkeys != biometric auth
  - CatWChainsaw 2y ago
    Technically correct yet I would not be surprised if they're still quite widely used. And the second part?
    - throwaway2056 2y ago
      All phones ask for PIN or pattern in addition to face/fingerprint. Use that. For the average user this is safe enough. (i.e) keep google/apple password safe. Then all is fine. > exporting and FAANG lock-in You don't ever have to even sign into FAANG if you can put up with inconvenience. - Buy a U2F FIDO key like OPEN SOURCE https://solokeys.com/ https://solokeys.com/ or Yubikey etc - You can register this key directly at the website or - Use https://bitwarden.com/passwordless-passkeys/ https://bitwarden.com/passwordless-passkeys/ - Every password manager need to implement it obviously
livueta 2y ago
I'm honestly bamboozled why anyone gives passkeys the time of day, given the mess that is attestation and its ability to enforce user-hostile ecosystem lockin: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 https://news.ycombinator.com/item?id=39698502 https://news.ycombinator.com/item?id=39698502 https://news.ycombinator.com/item?id=39706876 https://news.ycombinator.com/item?id=39706876 In principle, it's a great idea. This specific implementation should be treated as DoA because of how attestation works.
- Nathanba 2y ago
  the principle is the reason why I am staying up to date on this. In principle I would feel better if the stuff stored in my bitwarden account are hardware related keys that do not help an attacker even if they guessed my master password and downloaded them all. I consider that an important security benefit... although honestly at this point I don't even know anymore if this is still true given that passkeys now sync across hardware... surely...
- pmontra 2y ago
  I still don't understand what problem passkeys solve for me that my random passwords in my password manager didn't already solve. This is both about threat model and credentials management. Threat model: it seems to me that passwords protects against whom I want to be protected against. Credentials management: I sync my password manager db across my devices. If I lose one device for any reason, I have the passwords on the other ones and in the backup.
  - p0seidon 2y ago
    What all big platforms encounter is that the actual attacker already knows the password. That is because (1) it has been leaked on another platform and the user uses the same or (2) because it has been stolen from the computer of the user or (3) the user gave it away voluntarily because he has been phished. Most of the time it is (1) and (3). On Hacker News, we are a very tech-savvy group, and I agree if you stick to your approach that's secure. In a bigger view, that is absolutely not the reality for big B2C platforms. With passkeys (1) and (3) technically impossible and (2) is nearly impossible. Does that make sense?
foxylad 2y ago
The issues the article raises are real, but it paints passkey implementation as much harder than it actually is. It's in Corbado's interests to exaggerate the difficulties. We added passkeys to existing password authentication for a python flask app, and it took about 40 hours. 20 hours to get basic registration/authentication working, and another 20 hours to tweak the UX (things like popping up a "Want to use passkeys?" dialog occasionally, a passkeys page so users can manage them - all huge problems according to the article). So please don't put passkeys in the too-hard basket after reading this article. Users love them, and they are going to be ubiquitous very soon.
- bendavis381 2y ago
  This matches our experience too. Out of curiosity, do you use email as the identifier? And if so, do you verify during the initial signup flow?
  - p0seidon 2y ago
    We use email or phone number as the identifier. We recommend verifying on sign-up, but it is actually a configuration option. We have other customers who want to request OTP on the next sign-in. Not validating the identifier on sign-up comes with a long list of potential security/ux race conditions further down the chain (especially if you also support social logins). What is your approach?
  - foxylad 2y ago
    Yes, we use email as the identifier, and yes we verify on signup. We certainly aren't exceptional, and I expect that implementation will become easier as passkeys become more popular, and browser/device APIs develop. So hopefully later adopters will find it even easier than we did.
- doctorpangloss 2y ago
  Why not use Keycloak, then add OIDC to your Flask app, in 4h?
  - 2y ago
byyll 2y ago
Conflict of interest coming from a company selling passkey implementation.
hedora 2y ago
This thread is a great survey of why the passkey roll out is so controversial. Even without the inevitable “but what if Google/Apple permabans me?” thread, we have confusion about whether QR codes are sufficient, biometrics are necessary, and a baffling UI that maybe means to say “debug the bluetooth stacks on whatever devices are nearby”.
- umvi 2y ago
  You can use yubikeys as passkeys, if you are afraid of a Google/Apple ban
  - sph 2y ago
    What if you lose your yubikey? "Go enroll a new one in your 500 accounts" is not a good enough answer. The thing about a regular password manager is that it does not get lost.
    - mrtesthah 2y ago
      The point isn’t that we should have to trust Apple/Google for our passkeys — it’s that we should have full control over the backing store used by our password manager(s).
      - toomuchtodo 2y ago
        The standard supports exports, it should arrive; the vast majority of users will never export them from Google or iCloud synced storage though. https://news.ycombinator.com/item?id=35855133 https://news.ycombinator.com/item?id=35855133 ("HN: Passkeys will be importable, exportable, cross-device, and across managers")
        sph 2y ago
        I am unfamiliar with passkeys. Can they be exported and imported, or WILL it be possible one day? Because that affects my choice to adopt them today.
galaxyLogic 2y ago
Would it not be best if Passkey authorization was implemented as a service, so that not everybody have to re-implement the same thing?
- lo0dot0 2y ago
  No, decentralisation is a positive aspect of the internet.
alberth 2y ago
Dumb question: are passkeys essential a “login token” (binded to a device)?
- dcow 2y ago
  No. Passkeys aren't device bound but they are a challenge response protocol so no token transits the wire during auth flows. It’s why they are cryptographically more secure than a shared secret (token). However most implementations take the result of a passkey login and issue a session token so…
  - drdaeman 2y ago
    > However most implementations take the result of a passkey login and issue a session token so… Is there a way to avoid this and use token for every request in real world? I mean, that’s an interesting idea, but I think it’s not going to work in practice (can’t make user show face or touch a token on every request). Please let me know if I’m wrong here!
    - bux93 2y ago
      Well, every mutual TLS handshake authenticates again. And then establishes a session key. But if you fire up a new session (new tab?), boom, new mutual authentication. It's just that the private key is stored in a keystore, and not on a device, and you don't need to keep your finger on the fingerprint reader all the time. You could have every message signed with the sending party's private key, at some performance cost. And that signing could happen in a hardware device. Essentially what happens with hardware wallets for bitcoin.
    - dcow 2y ago
      You don’t have to if you have the notion of an active unlock session. Have you ever used aws sigv4 for s3 buckets? Pretty ubiquitous example of signed requests in practice.
  - zigzag312 2y ago
    AFAIK passkeys are not a protocol. They are cryptographic key pairs (public and private keys). Private key is stored on a device and public key on a server. Private key often is device bound, and it never leaves the device. That's where a challenge response protocol comes in. It enables to provide proof of private key ownership without exposing the private key and it should also prevent replay attacks.
deleted 2y ago
[deleted]
__MatrixMan__ 2y ago
These crop up every now and again but they never address my biggest concern, which how we can be sure that https://w3c.github.io/webauthn/#attestation-object https://w3c.github.io/webauthn/#attestation-object will not create a situation where only approved devices are allowed to authenticate. It's not hard to imagine Google and Apple and a few others finding ways to pressure authenticators into blocking access to users of devices that cannot prove that they're running firmware which bellyfeels ingsoc.
- agl 2y ago
  It is a fair worry. On one side, there are sites with regulations that they are supposed to meet and it's hard to do so without knowing something about the passkey provider. If we want to try and replace SMS OTP, which is depressingly easy to compromise, we can't ignore such things. On the other, we don't want to create a situation where it's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist. So far, we haven't done attestation for passkey providers at all. There is only the AAGUID, which is a spoofable identifer should any sites try to filter based on it. There are legitimate cases where sites are required to know more, but we're trying to find a path that doesn't lead to the problems that you worry about and, so far, are erring on the side of openness.
  - p0seidon 2y ago
    Disclaimer Corbado Co-Founder here: That passkeys (WebAuthn) as a standard can support different levels of security requirements in the future on a common ground is probably the best thing. Even with an unknown new passkey provider, that's still more secure for the average consumer on a broad scale with legitimate passkey providers being 99.9% of the market. For regulated entities, that's an important area of extension. But even for banks, passkeys can easily replace the first factor, as phishing there is the biggest concern. I would argue that Passkeys+SMS OTP for banking is probably far more secure than any other option currently available (even with the sad security of SMS OTP), just because consumers cannot give their First-Factor voluntary away to phishing... Well maybe not better that any option but a lot of them.
steve_taylor 2y ago
Fear, uncertainty and doubt is the sword Corbado wants to live by, so it's the sword it should die by. You shouldn't trust Corbado with your users because the risk is too high and there are much more trusted solutions such as Auth0. Its implementation of passkeys is much more user-friendly. It doesn't require users to enter their email address. On my Mac, for example, it's one click, one fingerprint, then I'm in.
ktosobcy 2y ago
Passwords may not be ideal but I will always take them (with 2FA/YK) over passkeys... the latter is just asking for trouble :/
- fifteen1506 2y ago
  I'd honestly prefer a standard login page (or aria fields well defined for all inputs) so my password manager could click 'login' automatically. On the other hand, most Password Managers now support Passkeys, including Bitwarden.
  - p0seidon 2y ago
    As a password manager user, nothing really changes. As you pointed out, you can use them on any major platform to actually hold your passkeys. The thing is, in the broader scale, password manager use is very low among average consumers. Passkeys are a form of built-in secure password manager for all consumers, without any action needed. This thread is full of different views, and there are also downsides to it, but in this sense, it's a free upgrade in security for the majority of consumers.
ffo 2y ago
Even though I work at a company that also supplies passkeys support to its customers, I feel it is worth for people to have a read of (1). The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. Oh, and if a customer ever wants to change the domain name for branding related stuff, is also where the fun starts. My 2 cents are that passwords/2fa, passkeys, federation and maybe soon verifiable credentials are concepts that will work for a long time in parallel. So, if you ever choose a system that does the "identity/authentication" plumbing work for you, I think you should focus solutions that are open source and allow you to mix and match the different concepts. IMO this applies to b2c and b2b alike ;-) [1] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
- growse 2y ago
  > The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. I'm struggling a little bit with the use case here. Yubikeys and other HSMs also don't allow you to export the key material, and sites should have account recovery flows for people who lose access to their devices / HSMs / password manager databases. Is it merely a convenience thing, or is there an actual problem that can only be solved by allowing key material export?
  - Macha 2y ago
    The difference is yubikeys have been mainly used in enterprise settings where the reset approach is "get IT to assign a new yubikey to your account or boot your old yubikey". Passkeys are aimed at the general consumer who has been a very rare user of the yubikey. Now you're back to trusting every user to physically keep track of their passkeys, rather than trusting a pool of IT admins.
  - wkat4242 2y ago
    The export is important in case you want to move to a different service or password manager.
idle_zealot 2y ago
I tried out making a passkey on passkeys.io just now. On an Android phone, up-to-date OS, Bitwarden set as the preferred password manager, the "create a passkey" button, when tapped, switches to a loading spinner very breifly, then resets. Nothing else happens. I guess I'm not going to be using any passkeys.
gregorvand 2y ago
Behind the scenes, 10+ companies are working on passkey export / import Great write up though, thanks for this
- p0seidon 2y ago
  Thanks. We have heard that also and we would appreciate it. In my experience, it is already difficult to find a technical compromise within a team of 5 people who like each other and work together for years. Finding a solution on the current scale of passkeys is really a big effort and at the end it also needs to be implemented, so I would not be surprised if it takes a long time for this to happen. Do you have an estimate?
red_admiral 2y ago
There have been times in the past where we took something moderately simple (random number generation once you've got a good entropy source; digital signatures) and turned them into a monster (Dual-EC DRBG; ECDSA). It turns out those were bad ideas. The more I read about passkeys, the more I feel we're creating a new monster here. I'm just glad there's no "alg:none" option included. If you have a device that can store and sign with resident keys for a private/public key infrastructure, I don't see why we need all the extra complexity unless you want to charge everyone $4.99/mo for a key management SaaS, or force the last remaining Win11 users who log in with a local account onto Microsoft Accounts and Windows Hello (which I understand is the only way to get passkeys in edge without third-party software or devices).
- jmakov 2y ago
  Um.. isn't today recommended to use ecdsa for ssh keys?
  - red_admiral 2y ago
    I personally recommend EdDSA - just one letter difference, but a very big one under the hood! (If you're using `-t ed25519` then you're using EdDSA.) EDIT: Github agrees with me: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent https://docs.github.com/en/authentication/connecting-to-gith... they recommend EdDSA/ed25519 as first option, and RSA as fallback. ECDSA is not in the list at all. EDIT2: gitlab (https://docs.gitlab.com/ee/user/ssh.html https://docs.gitlab.com/ee/user/ssh.html) also recommends ed25519 (which uses EdDSA for signatures). They'll grudgingly let you use ECDSA but point you to https://leanpub.com/gocrypto/read#leanpub-auto-ecdsa https://leanpub.com/gocrypto/read#leanpub-auto-ecdsa for a lecture on why it's a bad choice; there are actually more problems with it than the ones covered on that page that would be far harder to fix.
    - jmakov 2y ago
      Thank you for that and the linked resources, makes more sense now!

184 points by vdelitz 2y ago

I have a nodejs passkey implementation over at AuthC https://github.com/authcompanion/authcompanion2 https://github.com/authcompanion/authcompanion2 a simple user management server. For javascript developers https://github.com/MasterKale/SimpleWebAuthn https://github.com/MasterKale/SimpleWebAuthn has been a good way to get started with a poc before venturing deeper into webauthn (passkeys) spec.

grose 2y ago

Very thorough article, nice! I'll add some other pain points I experienced: - You need to let users register more than 1 passkey, but how to show them which is which? There are lists like this one[1] and FIDO provides a (maybe irrelevant?) list on their site[2] stuck inside of a JWT. I ended up using that JSON list + registration date + browser UA that registered it + "currently using" indicator when the current session derives from that specific passkey. Still kind of feels like a mess. - The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64, which doesn't have native browser support. Not a big deal (just a couple helper functions needed) but kind of confusing if you're trying to implement the client or server bits from scratch. [Edit: as explained by a reply below, this is part of the actual spec!] - I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. The APIs seem to be mutually exclusive, differentiated by some options (some of which are already deprecated?) and requiring empty lists to be passed in certain places. I'm trying to bolt on passkeys to a pre-existing auth flow and all I want is the closest thing to "use the browser's built in password manager". Ended up giving up on resident keys for now. [1]: https://github.com/passkeydeveloper/passkey-authenticator-aaguids/blob/main/aaguid.json https://github.com/passkeydeveloper/passkey-authenticator-aa... [2]: https://fidoalliance.org/metadata/ https://fidoalliance.org/metadata/

toomuchtodo 2y ago
Do you allow users to rename their passkeys in your user interface? I very much like how GitHub handles this, take a look in that view if you have a GitHub account. You also get nice info like "Seen from this browser" and "Synced" (non device bound passkeys) indicators if applicable. https://github.com/settings/security https://github.com/settings/security (Passkeys section) https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys https://docs.github.com/en/authentication/authenticating-wit...
- grose 2y ago
  That's a good idea, thanks for the suggestion! Maybe I'll let them rename the keys with the provider as the default name. Haven't played with GitHub's implementation yet but I'll play around with it.
agl 2y ago
> The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64 WebAuthn itself uses base64url rather than base64. See, e.g., the `id` field here: https://www.w3.org/TR/webauthn-2/#iface-pkcredential https://www.w3.org/TR/webauthn-2/#iface-pkcredential (It was probably a mistake, but it predates me so I don't know the motivation.) > I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. Non-discoverable credentials can only be used if their credential ID is passed in an allowlist. Discoverable credentials (a.k.a. "resident" in the API, although that name is a bit misleading) _can_ be enumerated in an allowlist. So they can work together, but to have the allowlist you must collect a username first or have some other way of know which account is pertinent to the current session.
- grose 2y ago
  Aha, so it is part of the spec. Thanks for clarifying that. Appreciate the advice on discoverable credentials as well! I was probably leaving out the discoverable creds from the allowlist. Getting the timing down for when to ask for credentials was a bit tricky but I think I see the whole picture now. I will say though, when it all works out it's a really nice way to log in, and my users are happy about it.
foxylad 2y ago
We ask the user to name each passkey. One more modal dialog during registration, but seems to work well.

tptacek 2y ago

Two assumptions I have, and I'd love for people to shoot me down on this: 1. Most applications will get "Passkey" support by dint of OIDC SSO support; OIDC IdPs are the things that will implement Passkeys (SIWA and SIWG for "retail" users). 2. Direct Passkey adoption in applications will round towards zero, maybe excepting huge applications like Insta; people will do Passkeys with their Google account, but not with (say) Doordash. If those premises hold, I probably don't need to be sold (though this post is helpful and incredibly detailed) on why not to do my own direct implementation of Passkeys; it makes more sense for us to nail OIDC.

simonw 2y ago
What you're saying mostly makes sense to me, but there's one big edge-case that I care about. For my own applications I like to have my staff-level admin access work independently of external providers. I don't want to run into a situation where my Google account (or some other SSO service) has been accidentally banned by a weird machine learning algorithm hiccup and now I can't sign into my own service's dashboard to sort out problems. Admin accounts are also exactly the kind of thing that I want to have my own 2FA for - so passkeys are ideal for them. So yeah, Passkeys for retail users is something I'll outsource to an IdP, but I'm still very interested in them for my own "staff-level" administrative accounts.
- kemotep 2y ago
  Yeah that’s a break glass account situation. Even with a self hosted IdP solution, it going down isn’t going to perform the OIDC SSO dance to get into whatever service so having that backup account or fallback authentication access is important.
johngalt 2y ago
100% That is exactly how it is playing out. People do not register (2passkeys * 20 services). They sign in with Google or Microsoft and call it a day. Privacy implications ignored. Even more true in Corp IT. People will learn to use passkeys with SSO at the office and take those habits home.

deleted 2y ago

[deleted]

snailmailman 2y ago

I still haven’t really migrated to passkeys yet. Until Bitwarden on iOS properly supports them I won’t fully switch. I don’t want to have to manage a passkey on every device. So I will wait until I can sync between all my devices. But when I did play with them a bit it seemed so full of weird pitfalls. Aren’t I supposed to be able to use my phones passkey to login on my PC with a QR code? I never got that to work. The article implies that might be a windows 10 vs 11 issue- but why? It’s a QR code. Windows 10 should be capable of displaying a QR code. I tried it just now. Windows pulls up a “making sure it’s you” box, with no buttons other than cancel, and no option to use the passkey from elsewhere. This computer doesn’t have a passkey, what is windows doing?

pat2man 2y ago
There is a Bluetooth part of the spec too. If your phone can’t talk to your computer via Bluetooth it won’t work.
- deleted 2y ago
  [deleted]
jeroenhd 2y ago
QR codes are usually the fallback method, I believe, because they're clunky and they suck if you need to do it more than once per week. Laptops and phones use Bluetooth Low Energy (among others) to communicate (CTAP 2.2) which is what your computer may be waiting on. I can't tell you why you couldn't log in, I use Bitwarden's passkeys and they work reliably for me. If you want the added security your phone's hardware encryption provides, I believe there are a few annoyances, particularly with the way Android 13 and lower, but I haven't had to look into those yet.

zie 2y ago

tldr; It's still a giant mess, and until browser developers get around to fixing it, it's probably better to punt on Passkeys for now. The question is, can the mess get fixed enough before developers like me give up and move on to something else. I gave up a while ago, figured I'd check back in a few years. My current guess: I'll never have to implement them.

jillesvangurp 2y ago
That's my current impression as well. The companies involved are more interested in making themselves the center of the universe than in collaborating to address the rather obvious user and developer experience issues. Nobody seems in a hurry to do this. It's the same reason why previous attempts at federated identity have fizzled out. Both MS and Google loved the idea of the whole world using them exclusively as the only identity provider but then balked at the notion of their users using an identity provider that wasn't them. Passkey is a repeat of this. Apple loves the idea of people using iphones to identify with whatever. Android, not so much. And MS of course wants to keep a tight grip on passkey's used to sign into Office, Windows, etc.
p0seidon 2y ago
Disclaimer: Co-Founder Corbado here. I think the simplicity actually for the user is why they are so successful already. I can understand a lot of the criticism, although I am not that skeptical regarding the lock-in. I think this discussion is probably already lost with most consumers having their life within Google or Apple cloud via the mobile phone. Although the discussion is valuable, it should not be held over passkeys. For passkeys, we truly believe even if those options are weighed against each other, the benefits are weighing more. Big consumer-facing platforms have huge problems securing accounts for users. If you force them to use classic MFA (SMS or TOTP), the usage drops and recovery/fallback processes skyrocket. They don't want MFA. Risk-based MFA can help but is not perfect as attacks get more precise. So we think the adoption will be faster than browser developers can get around fixing all of the issues, because once a standard is adopted, it gets more and more difficult to streamline things. But we are looking forward to it. Of course, we see it that way, because we are building a company around it, but I have been battling against account takeover for years and took great pride in trying to protect the data as a developer, our users entrusted us. So I see a real chance here to improve security in the consumer market.

CatWChainsaw 2y ago

About three weeks ago, I grabbed some samples out of a freezer at -80C without gloves because it was quick. Yes it was stupid! (It's also quite common that someone who needs to "grab one sample real quick" does this.) The fingers on my right hand felt prickly for a couple minutes after that but no harm, it seemed. Well it took a couple weeks but the fingertips on my right hand all started blistering and one finger basically has a second-degree burn. My left hand, which I didn't use on the freezer, seems to be experiencing mirroring blisters, and I have no explanation since I didn't do anything (stupid or otherwise) to burn/blister them. If I were relying on passkeys and I couldn't register multiple keys, like one for each of my ten fingers plus face plus hardware token, I'd be locked out of my passkey-protected accounts for... I mean I honestly don't know how long, my fingerprints could still be healing a month from now. So between that and the kinks that still need to be worked out regarding exporting and FAANG lock-in, I'll keep using my passwords. And wearing gloves when using -80C freezers.

shepherdjerred 2y ago
Passkeys != biometric auth
- CatWChainsaw 2y ago
  Technically correct yet I would not be surprised if they're still quite widely used. And the second part?
  - throwaway2056 2y ago
    All phones ask for PIN or pattern in addition to face/fingerprint. Use that. For the average user this is safe enough. (i.e) keep google/apple password safe. Then all is fine. > exporting and FAANG lock-in You don't ever have to even sign into FAANG if you can put up with inconvenience. - Buy a U2F FIDO key like OPEN SOURCE https://solokeys.com/ https://solokeys.com/ or Yubikey etc - You can register this key directly at the website or - Use https://bitwarden.com/passwordless-passkeys/ https://bitwarden.com/passwordless-passkeys/ - Every password manager need to implement it obviously

livueta 2y ago

I'm honestly bamboozled why anyone gives passkeys the time of day, given the mess that is attestation and its ability to enforce user-hostile ecosystem lockin: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 https://news.ycombinator.com/item?id=39698502 https://news.ycombinator.com/item?id=39698502 https://news.ycombinator.com/item?id=39706876 https://news.ycombinator.com/item?id=39706876 In principle, it's a great idea. This specific implementation should be treated as DoA because of how attestation works.

Nathanba 2y ago
the principle is the reason why I am staying up to date on this. In principle I would feel better if the stuff stored in my bitwarden account are hardware related keys that do not help an attacker even if they guessed my master password and downloaded them all. I consider that an important security benefit... although honestly at this point I don't even know anymore if this is still true given that passkeys now sync across hardware... surely...
pmontra 2y ago
I still don't understand what problem passkeys solve for me that my random passwords in my password manager didn't already solve. This is both about threat model and credentials management. Threat model: it seems to me that passwords protects against whom I want to be protected against. Credentials management: I sync my password manager db across my devices. If I lose one device for any reason, I have the passwords on the other ones and in the backup.
- p0seidon 2y ago
  What all big platforms encounter is that the actual attacker already knows the password. That is because (1) it has been leaked on another platform and the user uses the same or (2) because it has been stolen from the computer of the user or (3) the user gave it away voluntarily because he has been phished. Most of the time it is (1) and (3). On Hacker News, we are a very tech-savvy group, and I agree if you stick to your approach that's secure. In a bigger view, that is absolutely not the reality for big B2C platforms. With passkeys (1) and (3) technically impossible and (2) is nearly impossible. Does that make sense?

foxylad 2y ago

The issues the article raises are real, but it paints passkey implementation as much harder than it actually is. It's in Corbado's interests to exaggerate the difficulties. We added passkeys to existing password authentication for a python flask app, and it took about 40 hours. 20 hours to get basic registration/authentication working, and another 20 hours to tweak the UX (things like popping up a "Want to use passkeys?" dialog occasionally, a passkeys page so users can manage them - all huge problems according to the article). So please don't put passkeys in the too-hard basket after reading this article. Users love them, and they are going to be ubiquitous very soon.

bendavis381 2y ago
This matches our experience too. Out of curiosity, do you use email as the identifier? And if so, do you verify during the initial signup flow?
- p0seidon 2y ago
  We use email or phone number as the identifier. We recommend verifying on sign-up, but it is actually a configuration option. We have other customers who want to request OTP on the next sign-in. Not validating the identifier on sign-up comes with a long list of potential security/ux race conditions further down the chain (especially if you also support social logins). What is your approach?
- foxylad 2y ago
  Yes, we use email as the identifier, and yes we verify on signup. We certainly aren't exceptional, and I expect that implementation will become easier as passkeys become more popular, and browser/device APIs develop. So hopefully later adopters will find it even easier than we did.
doctorpangloss 2y ago
Why not use Keycloak, then add OIDC to your Flask app, in 4h?
- 2y ago

byyll 2y ago

Conflict of interest coming from a company selling passkey implementation.

hedora 2y ago

This thread is a great survey of why the passkey roll out is so controversial. Even without the inevitable “but what if Google/Apple permabans me?” thread, we have confusion about whether QR codes are sufficient, biometrics are necessary, and a baffling UI that maybe means to say “debug the bluetooth stacks on whatever devices are nearby”.

umvi 2y ago
You can use yubikeys as passkeys, if you are afraid of a Google/Apple ban
- sph 2y ago
  What if you lose your yubikey? "Go enroll a new one in your 500 accounts" is not a good enough answer. The thing about a regular password manager is that it does not get lost.
  - mrtesthah 2y ago
    The point isn’t that we should have to trust Apple/Google for our passkeys — it’s that we should have full control over the backing store used by our password manager(s).
    - toomuchtodo 2y ago
      The standard supports exports, it should arrive; the vast majority of users will never export them from Google or iCloud synced storage though. https://news.ycombinator.com/item?id=35855133 https://news.ycombinator.com/item?id=35855133 ("HN: Passkeys will be importable, exportable, cross-device, and across managers")
      - sph 2y ago
        I am unfamiliar with passkeys. Can they be exported and imported, or WILL it be possible one day? Because that affects my choice to adopt them today.

galaxyLogic 2y ago

Would it not be best if Passkey authorization was implemented as a service, so that not everybody have to re-implement the same thing?

lo0dot0 2y ago
No, decentralisation is a positive aspect of the internet.

alberth 2y ago

Dumb question: are passkeys essential a “login token” (binded to a device)?

dcow 2y ago
No. Passkeys aren't device bound but they are a challenge response protocol so no token transits the wire during auth flows. It’s why they are cryptographically more secure than a shared secret (token). However most implementations take the result of a passkey login and issue a session token so…
- drdaeman 2y ago
  > However most implementations take the result of a passkey login and issue a session token so… Is there a way to avoid this and use token for every request in real world? I mean, that’s an interesting idea, but I think it’s not going to work in practice (can’t make user show face or touch a token on every request). Please let me know if I’m wrong here!
  - bux93 2y ago
    Well, every mutual TLS handshake authenticates again. And then establishes a session key. But if you fire up a new session (new tab?), boom, new mutual authentication. It's just that the private key is stored in a keystore, and not on a device, and you don't need to keep your finger on the fingerprint reader all the time. You could have every message signed with the sending party's private key, at some performance cost. And that signing could happen in a hardware device. Essentially what happens with hardware wallets for bitcoin.
  - dcow 2y ago
    You don’t have to if you have the notion of an active unlock session. Have you ever used aws sigv4 for s3 buckets? Pretty ubiquitous example of signed requests in practice.
- zigzag312 2y ago
  AFAIK passkeys are not a protocol. They are cryptographic key pairs (public and private keys). Private key is stored on a device and public key on a server. Private key often is device bound, and it never leaves the device. That's where a challenge response protocol comes in. It enables to provide proof of private key ownership without exposing the private key and it should also prevent replay attacks.

deleted 2y ago

[deleted]

__MatrixMan__ 2y ago

These crop up every now and again but they never address my biggest concern, which how we can be sure that https://w3c.github.io/webauthn/#attestation-object https://w3c.github.io/webauthn/#attestation-object will not create a situation where only approved devices are allowed to authenticate. It's not hard to imagine Google and Apple and a few others finding ways to pressure authenticators into blocking access to users of devices that cannot prove that they're running firmware which bellyfeels ingsoc.

agl 2y ago
It is a fair worry. On one side, there are sites with regulations that they are supposed to meet and it's hard to do so without knowing something about the passkey provider. If we want to try and replace SMS OTP, which is depressingly easy to compromise, we can't ignore such things. On the other, we don't want to create a situation where it's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist. So far, we haven't done attestation for passkey providers at all. There is only the AAGUID, which is a spoofable identifer should any sites try to filter based on it. There are legitimate cases where sites are required to know more, but we're trying to find a path that doesn't lead to the problems that you worry about and, so far, are erring on the side of openness.
- p0seidon 2y ago
  Disclaimer Corbado Co-Founder here: That passkeys (WebAuthn) as a standard can support different levels of security requirements in the future on a common ground is probably the best thing. Even with an unknown new passkey provider, that's still more secure for the average consumer on a broad scale with legitimate passkey providers being 99.9% of the market. For regulated entities, that's an important area of extension. But even for banks, passkeys can easily replace the first factor, as phishing there is the biggest concern. I would argue that Passkeys+SMS OTP for banking is probably far more secure than any other option currently available (even with the sad security of SMS OTP), just because consumers cannot give their First-Factor voluntary away to phishing... Well maybe not better that any option but a lot of them.

steve_taylor 2y ago

Fear, uncertainty and doubt is the sword Corbado wants to live by, so it's the sword it should die by. You shouldn't trust Corbado with your users because the risk is too high and there are much more trusted solutions such as Auth0. Its implementation of passkeys is much more user-friendly. It doesn't require users to enter their email address. On my Mac, for example, it's one click, one fingerprint, then I'm in.

ktosobcy 2y ago

Passwords may not be ideal but I will always take them (with 2FA/YK) over passkeys... the latter is just asking for trouble :/

fifteen1506 2y ago
I'd honestly prefer a standard login page (or aria fields well defined for all inputs) so my password manager could click 'login' automatically. On the other hand, most Password Managers now support Passkeys, including Bitwarden.
- p0seidon 2y ago
  As a password manager user, nothing really changes. As you pointed out, you can use them on any major platform to actually hold your passkeys. The thing is, in the broader scale, password manager use is very low among average consumers. Passkeys are a form of built-in secure password manager for all consumers, without any action needed. This thread is full of different views, and there are also downsides to it, but in this sense, it's a free upgrade in security for the majority of consumers.

ffo 2y ago

Even though I work at a company that also supplies passkeys support to its customers, I feel it is worth for people to have a read of (1). The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. Oh, and if a customer ever wants to change the domain name for branding related stuff, is also where the fun starts. My 2 cents are that passwords/2fa, passkeys, federation and maybe soon verifiable credentials are concepts that will work for a long time in parallel. So, if you ever choose a system that does the "identity/authentication" plumbing work for you, I think you should focus solutions that are open source and allow you to mix and match the different concepts. IMO this applies to b2c and b2b alike ;-) [1] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...

growse 2y ago
> The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. I'm struggling a little bit with the use case here. Yubikeys and other HSMs also don't allow you to export the key material, and sites should have account recovery flows for people who lose access to their devices / HSMs / password manager databases. Is it merely a convenience thing, or is there an actual problem that can only be solved by allowing key material export?
- Macha 2y ago
  The difference is yubikeys have been mainly used in enterprise settings where the reset approach is "get IT to assign a new yubikey to your account or boot your old yubikey". Passkeys are aimed at the general consumer who has been a very rare user of the yubikey. Now you're back to trusting every user to physically keep track of their passkeys, rather than trusting a pool of IT admins.
- wkat4242 2y ago
  The export is important in case you want to move to a different service or password manager.

idle_zealot 2y ago

I tried out making a passkey on passkeys.io just now. On an Android phone, up-to-date OS, Bitwarden set as the preferred password manager, the "create a passkey" button, when tapped, switches to a loading spinner very breifly, then resets. Nothing else happens. I guess I'm not going to be using any passkeys.

gregorvand 2y ago

Behind the scenes, 10+ companies are working on passkey export / import Great write up though, thanks for this

p0seidon 2y ago
Thanks. We have heard that also and we would appreciate it. In my experience, it is already difficult to find a technical compromise within a team of 5 people who like each other and work together for years. Finding a solution on the current scale of passkeys is really a big effort and at the end it also needs to be implemented, so I would not be surprised if it takes a long time for this to happen. Do you have an estimate?

red_admiral 2y ago

There have been times in the past where we took something moderately simple (random number generation once you've got a good entropy source; digital signatures) and turned them into a monster (Dual-EC DRBG; ECDSA). It turns out those were bad ideas. The more I read about passkeys, the more I feel we're creating a new monster here. I'm just glad there's no "alg:none" option included. If you have a device that can store and sign with resident keys for a private/public key infrastructure, I don't see why we need all the extra complexity unless you want to charge everyone $4.99/mo for a key management SaaS, or force the last remaining Win11 users who log in with a local account onto Microsoft Accounts and Windows Hello (which I understand is the only way to get passkeys in edge without third-party software or devices).

jmakov 2y ago
Um.. isn't today recommended to use ecdsa for ssh keys?
- red_admiral 2y ago
  I personally recommend EdDSA - just one letter difference, but a very big one under the hood! (If you're using `-t ed25519` then you're using EdDSA.) EDIT: Github agrees with me: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent https://docs.github.com/en/authentication/connecting-to-gith... they recommend EdDSA/ed25519 as first option, and RSA as fallback. ECDSA is not in the list at all. EDIT2: gitlab (https://docs.gitlab.com/ee/user/ssh.html https://docs.gitlab.com/ee/user/ssh.html) also recommends ed25519 (which uses EdDSA for signatures). They'll grudgingly let you use ECDSA but point you to https://leanpub.com/gocrypto/read#leanpub-auto-ecdsa https://leanpub.com/gocrypto/read#leanpub-auto-ecdsa for a lecture on why it's a bad choice; there are actually more problems with it than the ones covered on that page that would be far harder to fix.
  - jmakov 2y ago
    Thank you for that and the linked resources, makes more sense now!