5 ms·
> 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
by crote 3y ago
> 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.
This glances over one of the most powerful features of non-resident (not Passkey, regular U2F / Webauthn) keys: you don't actually need to store the private key on the client!
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.
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 all registered IDs for all 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.
Passkeys have been heavily pushed by major tech companies as a replacement for both a username, password, and 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.
- dyml 3y agoYou make a valid point about “non-resident” WebAuthn 2FA being great 2FA. However, passkeys are also great, and they depend on your context…. Most people are in the passkey context. For people who are not knee-deep I think we can explain it a bit better, why passkeys replaces passwords: With non-resident (2FA keys) you need to identify your account first. Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords. With passkeys, the website can just ask your browser) to sign in with any of the accounts it has passkeys for; which result in a one click sign in. While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key) Source: I work at Bitwarden building our Passkey API for developers. We support both 2FA and passkeys, both in the API service and in our password manager. Feel free to ask my anything related.
- ivlad 3y ago> Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords. Nothing prevents site from sending a blob of random data when real key is not found. > While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key) Both major desktop operating systems come with WebAuthn support - Windows via Windows Hello and macOS with Secure Enclave backed key store. That not a problem at all in corp environment. Buying a Yubikey (or two) for each employee in the company is minimal cost comparing to laptop, desk, chair, software licenses We use WebAuthn as the first factor, and we love it because it completely eliminated password brute force problem. Password attacks (brute force and stuffing) is a much bigger problem, than account enumeration, especially in corp environments where usernames follow a name-based pattern and everybody is on LinkedIn. BTW, we are paid Bitwarden customer, and our Helpdesk was not too happy when Bitwarden update resulted unexpected prompt interrupting WebAuthn authentication flow for users. )
- Borealid 3y agoYou don't need a password to prevent account enumeration; you can send people who choose a nonexistent account a bogus credential that the token won't accept. You have to display the password prompt for invalid accounts to avoid enumeration without webauthn too...