> With a security key, the private key is stored inside a secure element and an attacker with physical access to a security key would not be able to recover the private key value.<p>This glances over one of the most powerful features of non-resident (not Passkey, regular U2F / Webauthn) keys: you don't actually <i>need</i> to store the private key on the client!<p>Non-resident keys only use a single per-token secret key. On registration a random number is generated, which is used together with the secret key to derive a public/private keypair used for the whole authentication flow. This random number is sent to the server along with some check digits, forming a token ID. On authentication the server sends the ID back to the token, who uses it to again derive the same keypair which is for authentication. The biggest benefit is that a single cheap token can support an unlimited number of websites. It only needs to store a single secret, after all. If the user has multiple hardware tokens, just send all the numbers one-by-one and see which one is accepted by the token. This also provides essentially perfect privacy: the token doesn't store anything about the websites or accounts it is used with, so an attacker gaining control over a token cannot easily determine where it can be used and has to manually try each website one-by-one by actually visiting the site and trying potential usernames.<p>With resident keys ("Passkeys") the website does not know which ID to return, because a username is not yet known so you'd have to try <i>all</i> registered IDs for <i>all</i> users to look for a match. That's impossible, so the token needs to store some per-user-account data which allows it to map from a domain name to one or more stored credentials and their IDs (which allow both authentication and a mapping to a specific user on login). This places a hard upper limit to the number of Passkey websites a security key can support, and in practice forces you to use a smartphone or computer instead if you want to register a nontrivial number of websites. There are also privacy risks here, as it must by definition be possible to query a token for the existence of an account at a website.<p>Passkeys have been heavily pushed by major tech companies as a replacement for both a username, password, <i>and</i> 2FA method - but (assuming proper 2FA) it's a strict downgrade with serious drawbacks. It's really sad to see companies ditching proper Webauthn 2FA support when switching to Passkeys, because it's making security worse for the people who actually care about it.
I wish the support of real tokens would also benefit from the attention Passkeys receive though. They use the same protocol after all.<p>On Firefox on Android I still get the message that physical tokens are not supported on mobile when I try to authenticate to e.g. PayPal. I don't really like Passkeys because I prefer the security of real tokens (yubikeys). And I don't want to register with big tech companies to be able to use passkeys - for example I don't even have a google account logged in on my android phone.
There are some things I don't quite understand with passkeys.<p>People say it's meant to replace login/password, not act as 2FAs. Yet last I tried on Google having a login/password is mandatory, the passkey is just used as 2FA. So what's the point to convert my 2FA yubikey to a passkey?<p>Also, my understanding is that passkeys are standalone keys. There doesn't seem to be any support for federation of various keys by having them signed by a master key, as in PGP, so that I can actually prove on service X that I'm also the same user on service Y, thus being able to link or verify accounts easily.
Meanwhile, Microsoft sabotages FIDO2/Firefox on office.com: <a href="https://news.ycombinator.com/item?id=38502340">https://news.ycombinator.com/item?id=38502340</a>
I'd switch to passkeys immediately where possible, if Android/Google would allow third party password manager apps to provide and store them. Afaik they still want you to use the Google Password Manager, which is not an option for me.
My main beef with Passkeys is that there is no hardware attestation.<p>With Yubikeys, the relying party has a cryptographic way to ensure that the key is generated on a Yubikey, and can even validate the specific Yubikey hardware version.<p>AFAIK, with Passkeys you can't do that. You have to trust that it was generated and stored securely and not just some software emulation.<p>The Passkey manufacturers argue this is because Passkeys are intended to be transferable between devices. But I can't believe there is no form of attestation possible just because you are transferring the keys around, afterall it should be possible to attest that <i>"these bytes were signed by a key in a $this_device secure enclave and the key was securely imported to the device secure enclave via $manufacturer Passkey process"</i> or something along those lines, no ?
Let me add an operations and service delivery perspective. Our company relies solely on Passkeys for sign-in. The experience is both insanely good yet annoying.<p>A colleague summarized our latest Passkey issues showing the ecosystem remains fragile for enterprises:<p>Fragile Passkey Ecosystem for Enterprises
<a href="https://news.ycombinator.com/item?id=39742107">https://news.ycombinator.com/item?id=39742107</a>
At pico.sh we are developing a completely different type of passwordless authentication all leveraging what developers are already familiar with: SSH keys.<p>No passwords, no JWTs, no bearer tokens, no complicated webauthn, and no passkeys. All we need is an SSH keypair.<p>We have a demo if you are interested in learning more: <a href="https://pico.sh/tunnels" rel="nofollow">https://pico.sh/tunnels</a>
With SMS otp, it's possible to associate 2 phone numbers (or more) to a single account.<p>That way if my wife and I can use her Amazon account.<p>Can the same paradigm be grafted to pass-keys/webauthn?<p>Maybe a useful flow could be<p>You can log in with any of the following:<p>a) passkey
b) email and sms and password verification
c) customer service<p>Its not 100% air tight; but it seems better than the current state of affairs.
Passkeys so far look like a repeat of previous efforts to move away from passwords or make logins more secure (e.g. Openid, webauthn, 2FA).<p>There are two problems:<p>1) this stuff is hard to explain to end users. This is the reason it's not widely used yet even on the handful of platforms that provide this option.<p>2) Big companies are being very proprietary and selfish about this stuff. So you have Google insisting on Chrome and Google password manager and insisting this all gets routed via your phone. And Apple does the same with Safari and their password manager. And of course MS is doing their own thing. Meanwhile, Firefox doesn't even support this stuff properly yet so it's impossible to roll out something that only supports passkeys and nothing else.<p>The second one is the big problem because companies like Google and Microsoft get all starry eyed when they realize that all passkey approvals go via property they control. So, they have a natural tendency to prevent people from using anything else than that. The same happened with OpenID. Both MS and Google were all over it. But they couldn't bring themselves to federate each other's identities. I mean people signing into gmail with a hotmail address or vice versa. The thought alone was causing panics at executive levels in both companies. So, they crippled it and over complicated it. And then proceeded to waffle on the standards so they could have mutually incompatible implementations be standard.