13 ms·

A Tour of WebAuthn

299 points by caust1c 2y ago

OtomotO 2y ago
[flagged]
- arccy 2y ago
  and yet everyone recommends ssh keys over passwords. passkeys are just the ssh keys of the web
  - onli 2y ago
    Ssh keys are files that can be moved easily from device to device. That's very different to using e.g. your proprietary macbook internals as your login key. Completely different lock-in.
    - Scion9066 2y ago
      A passkey is a synced, discoverable WebAuthn credential. While many implementations protect the private keys with additional security measures like secure enclaves or TPMs, it's not required. If you want to use an implementation that doesn't use those types of lock-ins, even when they're there to protect your credentials, you can. Multiple software-only implementations exist.
      - eikenberry 2y ago
        Until they start trying to enforce attestation. Then your only choice will be giving a large corporation control over your online access.
    - aseipp 2y ago
      You can just enroll multiple keys from different devices, just like you do with SSH, that's the recommended way. But even then, there are software implementations of WebAuthn, like 1Password. You can then use the local TPM as a "last mile" authentication mechanism to quickly and effectively unlock your local encrypted password database and then get the needed key material to do WebAuthn. I use this across all my devices e.g. to login to GitHub, even on my iPhone. You could accomplish something fairly similar to this for SSH keys actually (an encrypted sync layer + deriving master keys from a local trusted source), but I don't think anyone has done this to the same level of polish.
    - pabs3 2y ago
      You can do passkeys in software too: https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
  - timewizard 2y ago
    [dead]
- paulddraper 2y ago
  > I don't give a fuck if other people can't manage secure passwords. I infer that you use a password manager. Consider passkeys as a standardized interface for password managers.
  - OtomotO 2y ago
    I do, so I have a working solution. I am not migrating to something just because it's new. My solution works for me. If it doesn't anymore, I'll see what I'll do. Depending on the service I'll swallow the bitter pill and use another solution or simply not use the service anymore. Every and any decision has consequences, on any side.
    - paulddraper 2y ago
      https://f8n-ipfs-production.imgix.net/QmaangUFNxGD6vRjnqzVnL2DaFgx4QX38F2LkxZY8WJqkK/nft.jpg https://f8n-ipfs-production.imgix.net/QmaangUFNxGD6vRjnqzVnL...
      - OtomotO 2y ago
        Thank you, this made my day :)
  - sam_lowry_ 2y ago
    > Consider passkeys as a standardized interface for password managers. I have not followed WebAuthn spec for a while but I vaguely remember that the spec discouraged software-only authenticators. Which made me feel like WebAuthn is yet another attempt to take the power from users and even states and concentrate it in the hands of a few multinationals controlled by US government. Pretty much what happened to Certificate Authorities and the push to use HTTPS everywhere. Of course there are benefits to HTTPS Everywhere and to passwordless authentication. But they do not outweight concerns over the digital autonomy of my country.
    - paulddraper 2y ago
      1Password supports passkeys, and I am sure that others do as well. Given the convenience factor (no extra install), I imagine that device/platform passkeys to be the most popular, but there should be no problem with using alternatives.
- growse 2y ago
  > I don't give a fuck if other people can't manage secure passwords. Sure you do. When your local tax office / hospital / large data holder of your personal data has an administrative interface that only uses passwords, then the administrator gets fished and your identity stolen, suddenly you care a great deal.
  - jiggawatts 2y ago
    Or they store your password insecurely — plain text or merely “encrypted” with XOR. I still see both of those regularly.
  - dheera 2y ago
    Everything boils down to some password or key (effectively a long password) access to some SQL instance. Anything on top of that is just fluff. The database can still be compromised directly.
    - growse 2y ago
      There's a difference between fluffy that's phishable (passwords) and fluff that isn't (webauthn). Not all fluff is equal.
      - dheera 2y ago
        How is Webauth'n Crunch not phishable? Most implementations throw about 20 "recovery codes" at you and at the absolute fucking worst possible moment while the user is trying to do something urgent, they say "save these in a secure place right now". It's not 1, but 20 passwords that ALL give access to your account. Where do you think those codes go? They are not only phishable, but they usually end up in a Google doc, screenshotted and pasted to Notion, or some other insecure place.
        growse 2y ago
        We're talking about webauthn, not recovery codes.
- simonw 2y ago
  We have decades of supporting evidence that passwords are rubbish at this point. Congratulations on being able to maintain good password habits yourself. It sounds like you already know how vanishingly rare that is.
- deleted 2y ago
  [deleted]
xenophonf 2y ago
I've always wanted to write a serverless OIDC provider/SAML IdP but got stymied by the WebAuthn standards, which don't seem to be written for normal people. :( But this e-book looks like it might have enough actual code interleaved with exposition to serve as more than just a high-level intro.
- caust1c 2y ago
  Adam Langley is probably one of the most gifted teachers when it comes to explaining cryptography concepts. Very clear, concise, precise, and makes it simple enough for me to follow without getting my neurons all knotted up.
  - jf 2y ago
    Agreed, I implemented TLS key pinning for a project at Okta using one of Adam's blog posts
- cyberax 2y ago
  OIDC providers are surprisingly NOT complicated! I created one to implement single sign-on with AWS, and it ended up being only around 200 lines of code in Go. All you need to do is create a JSON blob that is signed by a public key that is known to the consumer of the IDP. I'll need to do a write-up for it.
- nmadden 2y ago
  Yes, the WebAuthn spec is pretty unreadable. Every time I open it I feel like I’m lost in a maze of twisty hyperlinks, all alike.
treve 2y ago
Looks like an amazing resource for webauthn. Currently diving into this so it comes at a nice time for me. But it's also great advertising against WebAuthn. Hard to believe that this kind of complexity is needed, but as with OpenID Connect it feels like enterprise interests are running the ship, not end-users. Ease of implementation seems like a non-goal.
ggm 2y ago
It interested me how quickly all of my auth methods started to include "pick the right one of three presented numbers" tests after TOTP got widespread. I'm guessing there is some replay method which they wanted to prevent? This is distinct from in protocol large random value challenges, it must be to ensure a Hooman, or very numerate dog is actually present.
- g_p 2y ago
  TOTP codes are phishable and repayable in real-time - both via web (visiting the wrong site which asks for a TOTP and relays it within a few seconds), and via social engineering over the phone (give us one of the codes to prove it's you and we can keep your account safe). Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.
- hirsin 2y ago
  Pick the right number is not secure (enough), unfortunately - MFA exhaustion leads to users hitting one of three at random in an attempt to "make the notifications stop" (that are, naturally, being spammed by the attacker with a password but no mfa). The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in. This is why it's switched on good platforms to "type in the number you see", which mitigated this.
  - lxgr 2y ago
    That's slightly better against people essentially accidentally letting attackers in, but still completely phishable by e.g. tech support scammers. The big advantage of WebAuthN is that (at least for sane implementations, including all I've seen) there just is no way to enter an attacker-provided number and/or supply a displayed code to an attacker.
lapcat 2y ago
> A passkey is a synced, discoverable WebAuthn credential. This is my fundamental problem with passkeys: I don't want to use any syncing service. To be clear, I don't want to deprive other people of the ability to sync their credentials; I simply want to opt out myself. I just want to be able to manually back up and restore my credentials, like I've always done with passwords, but the passkey vendors seem to want to refuse to give anyone this ability. The vendors claim that this is to make phishing impossible, but I abhor paternalism in all forms, and also it's suspicious that this paternalism forces people to use the syncing systems of the passkey vendors, which are usually paid subscriptions. So passkeys become an endless supply of money for the vendors. It's very telling that passkeys were designed and shipped without any export/import mechanism. You can plainly see the priority of the passkey vendors, which is to lock you in. Allegedly, export/import is coming sometime in the future, but I strongly suspect that they'll end up with some kind of "approved provider" system so that the big passkey vendors can retain absolute control and avoid giving power to the users.
- ylk 2y ago
  Just use a password manager that doesn't sync by itself then https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
  - g_p 2y ago
    The downside of this (at least in my personal view) is it's a regression from the elevated security you got with non-resident FIDO/U2F MFA. The moment you go "passkey" and have to use a system like the one you suggest, you need to trust software based storage of long term credentials. That isn't the case with a hardware FIDO2/U2F token, which has unlimited capacity for non-resident MFA keys the server holds for you to decrypt and use locally to sign login attempts. I liked that FIDO seemed to get towards hardware backed security modules for login, without cognitive load of worrying about number of sites and yubikey slot capacity. Resident Webauthn keys limit the number of sites you can have, and push you towards software based solutions (so you lose out on doing the crypto on the single purpose, limited platform that's dedicated to generating those signatures).
arianvanp 2y ago
There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don't agree and it's very confusing for end users. https://github.com/w3c/webauthn/issues/2038 https://github.com/w3c/webauthn/issues/2038 They apparently came up with a fix for this using something called Signals API but I don't think any browser implemented that yet. Just wanted to highlight that this part of the UX is hairy and hard to get right
- arnarbi 2y ago
  Chrome on desktop did: https://developer.chrome.com/docs/identity/webauthn-signal-api https://developer.chrome.com/docs/identity/webauthn-signal-a...
  - jesseendahl 2y ago
    Nice seeing you here! :)
  - 1oooqooq 2y ago
    now just 27 absurdly insane implementation hacks to solve. webauthn is the only spec born like a 60 yr old legacy technology with global adoption. everything about it is insane. they didn't even think about having more than one key plugged in (mostly because the use case was just so that the device own your identity so they never thought the use would have control over the hardware), and the solution is to just blink all the keys and use the first one the use touches while hoping the other keys with timeout before the use actually have to use them. so much insanity.
    - arnarbi 2y ago
      “They” in this case included me and this was a deliberate fix for poor UX many years ago. We definitely thought about it and we used to blink only the key that had a credential from the allow list, because like you we thought that made the most sense. But people got routinely stuck because they just tapped a different key out of habit and nothing happened. There was no way for the browser to tell them “not that key”. Best case the reports would say the key was dead because it didn’t blink. We changed it to blink all keys, so that if you tap the wrong one, the browser can at least tell you something sensible and get you unstuck. This wasn’t a hypothetical shot in the dark, but something we tested and actually worked well for real users. I don’t disagree that WebAuthn has grown well beyond anything we could call good spec design. But it’s worth remembering that there’s /a lot/ of context behind it, and that the average user doesn’t behave anything like an average HN reader. > hoping the other keys with timeout before the use actually have to use them Both Chrome and Android will cancel requests to all other keys. If your keys are locking up until a timeout it’s more likely the key itself is buggy.
tgsovlerkhgsel 2y ago
This is an excellent write-up that finally motivated me to try to understand the mess that was left behind as new standards kept being layered on top of each other. Given the requirement for discoverable credentials and sync, truly open/independent passkey implementations seem impossible/impractical. For example, you couldn't just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the "discoverable" part of the credentials through some kind of cloud service. (The cloud service wouldn't need to be trusted with the actual keys, but you couldn't operate without it.) As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into... With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed. Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there's endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out). And then people are surprised that users stick with passwords.
- deleted 2y ago
  [deleted]
- lxgr 2y ago
  There is no technical requirement for discoverable credentials in most scenarios. Sure, not having to type your username is nice, but I'll gladly still do that if it allows "passphrase-based paper-restore-able authenticators" such as the one you describe. (I have one of these, in fact!) Many services I use that do support WebAuthN allow either variant to be used (i.e. they'll prefer discoverable credentials but will work just fine with non-discoverable ones), and arguably that should be how almost everybody ought to implement it. Unfortunately, at least as many other services completely botch it, e.g. by making discoverable credentials mandatory, by allowlisting browsers (e.g. Paypal), allowlisting authenticators (e.g. my government's e-signature platform), or by using them in a functionally braindead way (e.g. Amazon, who for completely unfathomable reasons still requires TOTP behind WebAuthn, i.e. they replace the password with it, not the second factor). So far I haven't noticed a strong trend towards enforcing discoverable credentials, but let's please name and shame everybody doing that. It's completely unnecessary.
zcdziura 2y ago
Can anyone recommend a good dummy passkey provider to use when developing and testing RESTful authentication services that will rely on WebAuthn? Every example that I've seen online for interacting with a WebAuthn service assumes that you're working within the context of the browser and can use the Navigator APIs. I like to use regular ol' cURL when testing out API endpoints, and it would be great if there were some kind of dummy CLI program that I could use to generate the WebAuthn key agreements and materials.
- lxgr 2y ago
  What exactly are you trying to test? Is there even a non-browser standard/protocol for using WebAuthN (which is a web standard, after all)?
  - pabs3 2y ago
    There isn't even a non-JavaScript way to use WebAuthn, let alone a non-browser way to use it. You could manually rewrite the JS for each site into curl calls or something I suppose.
- echeese 2y ago
  In Chrome Devtools, in the bottom panel, you can select WebAuthn, click Enable virtual authenticator environment, and create all the test passkeys you desire.
Zamicol 2y ago
WebAuthn and passkeys are a disaster. Much of the specs were created behind closed doors and never done in a way where we could have had outside input. They're completely corporate driven and designed to control users not empower them.
- reddalo 2y ago
  I agree. I will not use them, not as a user, nor as a developer.
- pas 2y ago
  Ah yes the closed doors of the world wide web consortium. https://lists.w3.org/Archives/Public/public-webauthn/ https://lists.w3.org/Archives/Public/public-webauthn/ (nb. I'm not saying the folks were easy to work with or super open to discussion, but it was not some clandestine black kitchen where it was cooked up.)
  - lxgr 2y ago
    The working group is definitely quite corporate-driven – just look at who's most active in it! – and has made some bad decisions in the past (my favorite example being [1], which effectively either breaks the hardware authenticator experience for passkeys or helps Yubico sell more/higher capacity Yubikeys, depending on how you look at it). But I agree that one thing you can't accuse them of is not operating in the open. While I don't agree with some of their decisions, discussing feedback in Github issues as well as on public mailing lists is probably as transparent as it gets. [1] https://github.com/w3c/webauthn/issues/1822 https://github.com/w3c/webauthn/issues/1822
    - pas 2y ago
      ... arms in a wide shrug ... well, yes, and ... it was always like this, no? DARPA was defense money, Xerox PARC was corporate money. The one big success I can quickly name that's "pure" is the web from CERN. (Okay I looked up, SMTP, RFC 821 from 1982 submitted by Jon Postel from ISI USC. But emails with the familiar @ were invented at a for-profit company by Ray Tomlinson more than a decade earlier.) I'm not saying we should just slump into apathy, I'm just trying to point out that many mostly good things came from big corps. (And the usual problem is that they still hold the keys to the kingdom. For example see how hard it is to send mail to MS hosted email inboxes. And of course they hide behind "oh our users choose this aggressive level of filtering".)
_Algernon_ 2y ago
Just like every other piece on passkeys it does not justify them, at all. Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants). Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user's captivity in their ecosystems.
- reddalo 2y ago
  100% agree. Passwords + OTPs are the best solution, IMO. No big tech can control this, and it's easy to keep a grasp on all the credentials we have. WebAuthn? No, thanks.
  - formerly_proven 2y ago
    How does big tech exert control over your usage of WebAuthn?
    - eadmund 2y ago
      By enabling relying parties to blacklist or whitelist the devices their users are allowed to use. It’s one more brick in the wall preventing general-purpose computing. Want to authenticate to Banana Computers? Well, you have to use one of their oDevices, because they will not let you use a RoboPhone to store your passkeys.
      - lxgr 2y ago
        You seem to be thinking of attestation, which is not a thing anymore with at least Apple's and Google's implementation. (They both had it for their non-synchronizing device-bound authenticators, but have heavily or even entirely rolled that back in favor of passkeys.) And since any solution excluding either of these is a non-starter, ironically the passkey push has made WebAuthN more open when it comes to client choice. So while I agree that Apple and Google not allowing passkey exports (yet; I am cautiously optimistic that they'll eventually be pushed to offer that too) runs the risk of locking in non-sophisticated users, the future is looking very bright for everybody posting here at least.
eadmund 2y ago
The very first sentence is: > Passwords are rubbish. Hard, hard disagree. They’re really not. Password reuse is rubbish. Passwords human beings can remember are rubbish. But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish. There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it. The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove. I do agree that WebAuthn offers very real improvements over passwords (principally due to no longer being a shared secret), but it makes things worse for the users in a few ways. For one, the ability of relying parties to blacklist or whitelist authenticators tramples on the user’s freedom to use the software he wants. Attestation keys and enterprise attestation are user-hostile: users and servers are no longer equal parties. And finally, the user experience of passkeys with, say, a phone-based authenticator is miserable: one must interrupt one’s computer usage, pick up the phone, unlock the phone, open the notification and unlock the app, then put the phone down. All in all, while WebAuthn does offer real advantages, I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
- hahn-kev 2y ago
  The assumption that only one party knows the password is not always (maybe even usually) incorrect. Plenty of sites store the password in plain text or hash on the server side. Meaning it's very possible for both parties to know it.
  - hahn-kev 2y ago
    Ignore this, I misread what the author above wrote.
- lxgr 2y ago
  > But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish. No, they're still rubbish. Even if you make them 256 bit, passwords are bearer tokens which are reused across multiple authentications, which makes them replayable (if intercepted on the client, in transit, or server-side), phishable, social engineerable etc. > There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it. And that's unfortunately too little protocol to be secure for repeated authentications. > [...] principally due to no longer being a shared secret [...] No, that's not the most important part of WebAuthN. You could get most of the benefits, i.e. phishing and social engineering resistance, from running it as a symmetric encryption protocol as well. Asymmetric keys "only" make server-side storage less sensitive (in the same way that hashing does for regular passwords). > The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove. The same is true for WebAuthN! (The only counterpoint here is attestation, but that is no longer a thing ever since Apple and Google introduced cloud synchronization for their credentials.) The difference is that you now need at least some software, because the calculations are too difficult to do on pen and paper. > I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords. Then... just don't do that! There are several open source implementations FIDO for you to choose from at this point.
jgalt212 2y ago
Credential stuffing would be a much less effective strategy is web apps went back to string-based usernames, and not email-based ones. Also, I hit CTRL-F on this post for the term "portable", and I got zero hits. Both passwords and SSH keys are trivially portable. Not so much with WebAuthn passkeys.
- lxgr 2y ago
  Let's please not. Password recovery flows are hard enough to get right and usually suck; adding username recovery on top of that doubles the opportunity for locking legitimate users out.
  - jgalt212 2y ago
    I don't know if I agree about the level of risk here. All password managers store passwords AND usernames.
- lxgr 2y ago
  Hopefully it shouldn't take much to get there. Bitwarden/Vaultwarden already allows exporting the private key and (as far as I can tell) all other metadata required by another implementation to import them.
1vuio0pswjnm7 2y ago
No SNI: https://web.archive.org/web/20241223150914if_/https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html https://web.archive.org/web/20241223150914if_/https://www.im...

A Tour of WebAuthn

299 points by caust1c 2y ago

OtomotO 2y ago

[flagged]

arccy 2y ago
and yet everyone recommends ssh keys over passwords. passkeys are just the ssh keys of the web
- onli 2y ago
  Ssh keys are files that can be moved easily from device to device. That's very different to using e.g. your proprietary macbook internals as your login key. Completely different lock-in.
  - Scion9066 2y ago
    A passkey is a synced, discoverable WebAuthn credential. While many implementations protect the private keys with additional security measures like secure enclaves or TPMs, it's not required. If you want to use an implementation that doesn't use those types of lock-ins, even when they're there to protect your credentials, you can. Multiple software-only implementations exist.
    - eikenberry 2y ago
      Until they start trying to enforce attestation. Then your only choice will be giving a large corporation control over your online access.
  - aseipp 2y ago
    You can just enroll multiple keys from different devices, just like you do with SSH, that's the recommended way. But even then, there are software implementations of WebAuthn, like 1Password. You can then use the local TPM as a "last mile" authentication mechanism to quickly and effectively unlock your local encrypted password database and then get the needed key material to do WebAuthn. I use this across all my devices e.g. to login to GitHub, even on my iPhone. You could accomplish something fairly similar to this for SSH keys actually (an encrypted sync layer + deriving master keys from a local trusted source), but I don't think anyone has done this to the same level of polish.
  - pabs3 2y ago
    You can do passkeys in software too: https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
- timewizard 2y ago
  [dead]
paulddraper 2y ago
> I don't give a fuck if other people can't manage secure passwords. I infer that you use a password manager. Consider passkeys as a standardized interface for password managers.
- OtomotO 2y ago
  I do, so I have a working solution. I am not migrating to something just because it's new. My solution works for me. If it doesn't anymore, I'll see what I'll do. Depending on the service I'll swallow the bitter pill and use another solution or simply not use the service anymore. Every and any decision has consequences, on any side.
  - paulddraper 2y ago
    https://f8n-ipfs-production.imgix.net/QmaangUFNxGD6vRjnqzVnL2DaFgx4QX38F2LkxZY8WJqkK/nft.jpg https://f8n-ipfs-production.imgix.net/QmaangUFNxGD6vRjnqzVnL...
    - OtomotO 2y ago
      Thank you, this made my day :)
- sam_lowry_ 2y ago
  > Consider passkeys as a standardized interface for password managers. I have not followed WebAuthn spec for a while but I vaguely remember that the spec discouraged software-only authenticators. Which made me feel like WebAuthn is yet another attempt to take the power from users and even states and concentrate it in the hands of a few multinationals controlled by US government. Pretty much what happened to Certificate Authorities and the push to use HTTPS everywhere. Of course there are benefits to HTTPS Everywhere and to passwordless authentication. But they do not outweight concerns over the digital autonomy of my country.
  - paulddraper 2y ago
    1Password supports passkeys, and I am sure that others do as well. Given the convenience factor (no extra install), I imagine that device/platform passkeys to be the most popular, but there should be no problem with using alternatives.
growse 2y ago
> I don't give a fuck if other people can't manage secure passwords. Sure you do. When your local tax office / hospital / large data holder of your personal data has an administrative interface that only uses passwords, then the administrator gets fished and your identity stolen, suddenly you care a great deal.
- jiggawatts 2y ago
  Or they store your password insecurely — plain text or merely “encrypted” with XOR. I still see both of those regularly.
- dheera 2y ago
  Everything boils down to some password or key (effectively a long password) access to some SQL instance. Anything on top of that is just fluff. The database can still be compromised directly.
  - growse 2y ago
    There's a difference between fluffy that's phishable (passwords) and fluff that isn't (webauthn). Not all fluff is equal.
    - dheera 2y ago
      How is Webauth'n Crunch not phishable? Most implementations throw about 20 "recovery codes" at you and at the absolute fucking worst possible moment while the user is trying to do something urgent, they say "save these in a secure place right now". It's not 1, but 20 passwords that ALL give access to your account. Where do you think those codes go? They are not only phishable, but they usually end up in a Google doc, screenshotted and pasted to Notion, or some other insecure place.
      - growse 2y ago
        We're talking about webauthn, not recovery codes.
simonw 2y ago
We have decades of supporting evidence that passwords are rubbish at this point. Congratulations on being able to maintain good password habits yourself. It sounds like you already know how vanishingly rare that is.
deleted 2y ago
[deleted]

xenophonf 2y ago

I've always wanted to write a serverless OIDC provider/SAML IdP but got stymied by the WebAuthn standards, which don't seem to be written for normal people. :( But this e-book looks like it might have enough actual code interleaved with exposition to serve as more than just a high-level intro.

caust1c 2y ago
Adam Langley is probably one of the most gifted teachers when it comes to explaining cryptography concepts. Very clear, concise, precise, and makes it simple enough for me to follow without getting my neurons all knotted up.
- jf 2y ago
  Agreed, I implemented TLS key pinning for a project at Okta using one of Adam's blog posts
cyberax 2y ago
OIDC providers are surprisingly NOT complicated! I created one to implement single sign-on with AWS, and it ended up being only around 200 lines of code in Go. All you need to do is create a JSON blob that is signed by a public key that is known to the consumer of the IDP. I'll need to do a write-up for it.
nmadden 2y ago
Yes, the WebAuthn spec is pretty unreadable. Every time I open it I feel like I’m lost in a maze of twisty hyperlinks, all alike.

treve 2y ago

Looks like an amazing resource for webauthn. Currently diving into this so it comes at a nice time for me. But it's also great advertising against WebAuthn. Hard to believe that this kind of complexity is needed, but as with OpenID Connect it feels like enterprise interests are running the ship, not end-users. Ease of implementation seems like a non-goal.

ggm 2y ago

It interested me how quickly all of my auth methods started to include "pick the right one of three presented numbers" tests after TOTP got widespread. I'm guessing there is some replay method which they wanted to prevent? This is distinct from in protocol large random value challenges, it must be to ensure a Hooman, or very numerate dog is actually present.

g_p 2y ago
TOTP codes are phishable and repayable in real-time - both via web (visiting the wrong site which asks for a TOTP and relays it within a few seconds), and via social engineering over the phone (give us one of the codes to prove it's you and we can keep your account safe). Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.
hirsin 2y ago
Pick the right number is not secure (enough), unfortunately - MFA exhaustion leads to users hitting one of three at random in an attempt to "make the notifications stop" (that are, naturally, being spammed by the attacker with a password but no mfa). The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in. This is why it's switched on good platforms to "type in the number you see", which mitigated this.
- lxgr 2y ago
  That's slightly better against people essentially accidentally letting attackers in, but still completely phishable by e.g. tech support scammers. The big advantage of WebAuthN is that (at least for sane implementations, including all I've seen) there just is no way to enter an attacker-provided number and/or supply a displayed code to an attacker.

lapcat 2y ago

> A passkey is a synced, discoverable WebAuthn credential. This is my fundamental problem with passkeys: I don't want to use any syncing service. To be clear, I don't want to deprive other people of the ability to sync their credentials; I simply want to opt out myself. I just want to be able to manually back up and restore my credentials, like I've always done with passwords, but the passkey vendors seem to want to refuse to give anyone this ability. The vendors claim that this is to make phishing impossible, but I abhor paternalism in all forms, and also it's suspicious that this paternalism forces people to use the syncing systems of the passkey vendors, which are usually paid subscriptions. So passkeys become an endless supply of money for the vendors. It's very telling that passkeys were designed and shipped without any export/import mechanism. You can plainly see the priority of the passkey vendors, which is to lock you in. Allegedly, export/import is coming sometime in the future, but I strongly suspect that they'll end up with some kind of "approved provider" system so that the big passkey vendors can retain absolute control and avoid giving power to the users.

ylk 2y ago
Just use a password manager that doesn't sync by itself then https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
- g_p 2y ago
  The downside of this (at least in my personal view) is it's a regression from the elevated security you got with non-resident FIDO/U2F MFA. The moment you go "passkey" and have to use a system like the one you suggest, you need to trust software based storage of long term credentials. That isn't the case with a hardware FIDO2/U2F token, which has unlimited capacity for non-resident MFA keys the server holds for you to decrypt and use locally to sign login attempts. I liked that FIDO seemed to get towards hardware backed security modules for login, without cognitive load of worrying about number of sites and yubikey slot capacity. Resident Webauthn keys limit the number of sites you can have, and push you towards software based solutions (so you lose out on doing the crypto on the single purpose, limited platform that's dedicated to generating those signatures).

arianvanp 2y ago

There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don't agree and it's very confusing for end users. https://github.com/w3c/webauthn/issues/2038 https://github.com/w3c/webauthn/issues/2038 They apparently came up with a fix for this using something called Signals API but I don't think any browser implemented that yet. Just wanted to highlight that this part of the UX is hairy and hard to get right

arnarbi 2y ago
Chrome on desktop did: https://developer.chrome.com/docs/identity/webauthn-signal-api https://developer.chrome.com/docs/identity/webauthn-signal-a...
- jesseendahl 2y ago
  Nice seeing you here! :)
- 1oooqooq 2y ago
  now just 27 absurdly insane implementation hacks to solve. webauthn is the only spec born like a 60 yr old legacy technology with global adoption. everything about it is insane. they didn't even think about having more than one key plugged in (mostly because the use case was just so that the device own your identity so they never thought the use would have control over the hardware), and the solution is to just blink all the keys and use the first one the use touches while hoping the other keys with timeout before the use actually have to use them. so much insanity.
  - arnarbi 2y ago
    “They” in this case included me and this was a deliberate fix for poor UX many years ago. We definitely thought about it and we used to blink only the key that had a credential from the allow list, because like you we thought that made the most sense. But people got routinely stuck because they just tapped a different key out of habit and nothing happened. There was no way for the browser to tell them “not that key”. Best case the reports would say the key was dead because it didn’t blink. We changed it to blink all keys, so that if you tap the wrong one, the browser can at least tell you something sensible and get you unstuck. This wasn’t a hypothetical shot in the dark, but something we tested and actually worked well for real users. I don’t disagree that WebAuthn has grown well beyond anything we could call good spec design. But it’s worth remembering that there’s /a lot/ of context behind it, and that the average user doesn’t behave anything like an average HN reader. > hoping the other keys with timeout before the use actually have to use them Both Chrome and Android will cancel requests to all other keys. If your keys are locking up until a timeout it’s more likely the key itself is buggy.

tgsovlerkhgsel 2y ago

This is an excellent write-up that finally motivated me to try to understand the mess that was left behind as new standards kept being layered on top of each other. Given the requirement for discoverable credentials and sync, truly open/independent passkey implementations seem impossible/impractical. For example, you couldn't just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the "discoverable" part of the credentials through some kind of cloud service. (The cloud service wouldn't need to be trusted with the actual keys, but you couldn't operate without it.) As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into... With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed. Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there's endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out). And then people are surprised that users stick with passwords.

deleted 2y ago
[deleted]
lxgr 2y ago
There is no technical requirement for discoverable credentials in most scenarios. Sure, not having to type your username is nice, but I'll gladly still do that if it allows "passphrase-based paper-restore-able authenticators" such as the one you describe. (I have one of these, in fact!) Many services I use that do support WebAuthN allow either variant to be used (i.e. they'll prefer discoverable credentials but will work just fine with non-discoverable ones), and arguably that should be how almost everybody ought to implement it. Unfortunately, at least as many other services completely botch it, e.g. by making discoverable credentials mandatory, by allowlisting browsers (e.g. Paypal), allowlisting authenticators (e.g. my government's e-signature platform), or by using them in a functionally braindead way (e.g. Amazon, who for completely unfathomable reasons still requires TOTP behind WebAuthn, i.e. they replace the password with it, not the second factor). So far I haven't noticed a strong trend towards enforcing discoverable credentials, but let's please name and shame everybody doing that. It's completely unnecessary.

zcdziura 2y ago

Can anyone recommend a good dummy passkey provider to use when developing and testing RESTful authentication services that will rely on WebAuthn? Every example that I've seen online for interacting with a WebAuthn service assumes that you're working within the context of the browser and can use the Navigator APIs. I like to use regular ol' cURL when testing out API endpoints, and it would be great if there were some kind of dummy CLI program that I could use to generate the WebAuthn key agreements and materials.

lxgr 2y ago
What exactly are you trying to test? Is there even a non-browser standard/protocol for using WebAuthN (which is a web standard, after all)?
- pabs3 2y ago
  There isn't even a non-JavaScript way to use WebAuthn, let alone a non-browser way to use it. You could manually rewrite the JS for each site into curl calls or something I suppose.
echeese 2y ago
In Chrome Devtools, in the bottom panel, you can select WebAuthn, click Enable virtual authenticator environment, and create all the test passkeys you desire.

Zamicol 2y ago

WebAuthn and passkeys are a disaster. Much of the specs were created behind closed doors and never done in a way where we could have had outside input. They're completely corporate driven and designed to control users not empower them.

reddalo 2y ago
I agree. I will not use them, not as a user, nor as a developer.
pas 2y ago
Ah yes the closed doors of the world wide web consortium. https://lists.w3.org/Archives/Public/public-webauthn/ https://lists.w3.org/Archives/Public/public-webauthn/ (nb. I'm not saying the folks were easy to work with or super open to discussion, but it was not some clandestine black kitchen where it was cooked up.)
- lxgr 2y ago
  The working group is definitely quite corporate-driven – just look at who's most active in it! – and has made some bad decisions in the past (my favorite example being [1], which effectively either breaks the hardware authenticator experience for passkeys or helps Yubico sell more/higher capacity Yubikeys, depending on how you look at it). But I agree that one thing you can't accuse them of is not operating in the open. While I don't agree with some of their decisions, discussing feedback in Github issues as well as on public mailing lists is probably as transparent as it gets. [1] https://github.com/w3c/webauthn/issues/1822 https://github.com/w3c/webauthn/issues/1822
  - pas 2y ago
    ... arms in a wide shrug ... well, yes, and ... it was always like this, no? DARPA was defense money, Xerox PARC was corporate money. The one big success I can quickly name that's "pure" is the web from CERN. (Okay I looked up, SMTP, RFC 821 from 1982 submitted by Jon Postel from ISI USC. But emails with the familiar @ were invented at a for-profit company by Ray Tomlinson more than a decade earlier.) I'm not saying we should just slump into apathy, I'm just trying to point out that many mostly good things came from big corps. (And the usual problem is that they still hold the keys to the kingdom. For example see how hard it is to send mail to MS hosted email inboxes. And of course they hide behind "oh our users choose this aggressive level of filtering".)

_Algernon_ 2y ago

Just like every other piece on passkeys it does not justify them, at all. Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants). Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user's captivity in their ecosystems.

reddalo 2y ago
100% agree. Passwords + OTPs are the best solution, IMO. No big tech can control this, and it's easy to keep a grasp on all the credentials we have. WebAuthn? No, thanks.
- formerly_proven 2y ago
  How does big tech exert control over your usage of WebAuthn?
  - eadmund 2y ago
    By enabling relying parties to blacklist or whitelist the devices their users are allowed to use. It’s one more brick in the wall preventing general-purpose computing. Want to authenticate to Banana Computers? Well, you have to use one of their oDevices, because they will not let you use a RoboPhone to store your passkeys.
    - lxgr 2y ago
      You seem to be thinking of attestation, which is not a thing anymore with at least Apple's and Google's implementation. (They both had it for their non-synchronizing device-bound authenticators, but have heavily or even entirely rolled that back in favor of passkeys.) And since any solution excluding either of these is a non-starter, ironically the passkey push has made WebAuthN more open when it comes to client choice. So while I agree that Apple and Google not allowing passkey exports (yet; I am cautiously optimistic that they'll eventually be pushed to offer that too) runs the risk of locking in non-sophisticated users, the future is looking very bright for everybody posting here at least.

eadmund 2y ago

The very first sentence is: > Passwords are rubbish. Hard, hard disagree. They’re really not. Password reuse is rubbish. Passwords human beings can remember are rubbish. But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish. There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it. The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove. I do agree that WebAuthn offers very real improvements over passwords (principally due to no longer being a shared secret), but it makes things worse for the users in a few ways. For one, the ability of relying parties to blacklist or whitelist authenticators tramples on the user’s freedom to use the software he wants. Attestation keys and enterprise attestation are user-hostile: users and servers are no longer equal parties. And finally, the user experience of passkeys with, say, a phone-based authenticator is miserable: one must interrupt one’s computer usage, pick up the phone, unlock the phone, open the notification and unlock the app, then put the phone down. All in all, while WebAuthn does offer real advantages, I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.

hahn-kev 2y ago
The assumption that only one party knows the password is not always (maybe even usually) incorrect. Plenty of sites store the password in plain text or hash on the server side. Meaning it's very possible for both parties to know it.
- hahn-kev 2y ago
  Ignore this, I misread what the author above wrote.
lxgr 2y ago
> But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish. No, they're still rubbish. Even if you make them 256 bit, passwords are bearer tokens which are reused across multiple authentications, which makes them replayable (if intercepted on the client, in transit, or server-side), phishable, social engineerable etc. > There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it. And that's unfortunately too little protocol to be secure for repeated authentications. > [...] principally due to no longer being a shared secret [...] No, that's not the most important part of WebAuthN. You could get most of the benefits, i.e. phishing and social engineering resistance, from running it as a symmetric encryption protocol as well. Asymmetric keys "only" make server-side storage less sensitive (in the same way that hashing does for regular passwords). > The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove. The same is true for WebAuthN! (The only counterpoint here is attestation, but that is no longer a thing ever since Apple and Google introduced cloud synchronization for their credentials.) The difference is that you now need at least some software, because the calculations are too difficult to do on pen and paper. > I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords. Then... just don't do that! There are several open source implementations FIDO for you to choose from at this point.

jgalt212 2y ago

Credential stuffing would be a much less effective strategy is web apps went back to string-based usernames, and not email-based ones. Also, I hit CTRL-F on this post for the term "portable", and I got zero hits. Both passwords and SSH keys are trivially portable. Not so much with WebAuthn passkeys.

lxgr 2y ago
Let's please not. Password recovery flows are hard enough to get right and usually suck; adding username recovery on top of that doubles the opportunity for locking legitimate users out.
- jgalt212 2y ago
  I don't know if I agree about the level of risk here. All password managers store passwords AND usernames.
lxgr 2y ago
Hopefully it shouldn't take much to get there. Bitwarden/Vaultwarden already allows exporting the private key and (as far as I can tell) all other metadata required by another implementation to import them.

1vuio0pswjnm7 2y ago

No SNI: https://web.archive.org/web/20241223150914if_/https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html https://web.archive.org/web/20241223150914if_/https://www.im...