> 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.
You 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.
You 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...
> 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. )
A bit of a tangent but do you have a view on prices for hardware security keys like YubiKey? For private use they're a pricey option, especially if you get a few backup keys. Could a big actor like Google, if they wanted, scale up production, sell at cost and get prices down to say $2 each? Or is the components and manufacturing inherently more costly? Is there anything on the horizon that likely will bring much lower prices?
> 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.
Authentication which requires multiple independent mechanisms is rarely a user benefit though; it is the result of regulatory requirements or corporate risk aversion.
If companies are adopting passkeys, it likely means risk that they were formerly solving with a second factor (like weak/passive phishing resistance or credential reuse) are solved via baseline passkey provider behavior.
> 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.
You can protect this via the PIN of the security key, to prevent third parties who get access to your key (such as through coercion) seeing which websites you have accounts on.
For users who currently reuse weak passwords, passkeys are a security upgrade. For users who use strong unique passwords + FIDO keys, it is a downgrade. Both types of users exist.
Resident keys are good for SSH (I've done my part to make their use more accessible: https://bostik.iki.fi/aivoituksia/projects/yubikey-ssh.html), although the overall usability can still be improved. We are at an early stage of a new type of technology and people are still finding out what it can be even used for in realistic settings.
They are also good for enterprise deployments, where you can justify 2 (or 3) keys per user, and where you have a dedicated IT team to take care of account resets.
But resident keys for general website logins are a terrible idea. As other posters have already pointed out, the relevant security keys have a fixed number of key slots. Current best-of-breed hardware can store 25 resident keys. With only a small fraction of websites using WebAuthn, that limit is not an immediate concern - but considering the average user has about 100 online accounts[0], those slots will run out. Now consider that to have them be secure, the keys really can't be exportable. And in order to account for hardware failures and/or misplacements, you'd need a minimum of two such devices enrolled for each account.
The most depressing part of this all is that while passkeys are under the hood FIDO2 credentials, and their communication protocol is the same as with hardware devices, having a passkey support can indeed rule out physical devices. As the article points out, the transport specifier is different, and there is nothing that prevents an implementation to flat out reject anything other than "internal".
I wish the support of real tokens would also benefit from the attention Passkeys receive though. They use the same protocol after all.
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.
One issue is the limited support for resident keys on many hardware tokens. IIRC the limit on recent YubiKey 5 firmware versions is 25 resident keys. As Passkey adoption accelerates, people will hit that limit rather quickly.
Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).
Finally, only a tiny part of the population uses dedicated hardware tokens, whereas pretty much all popular password managers supports or will support Passkeys (Apple Keychain, 1Password, whatever the Chrome password manager is called, Samsung Pass, etc.).
So, it’s not surprising that hardware tokens are tested less these days.
(I don’t think that is a good, just trying to speculate on the reasons.)
> Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).
Chrome allows you to see stored resident keys and delete individual resident keys on any hardware token which supports CTAP 2.1. (to be fair, it is a bit hidden: Settings -> Privacy and security -> Security -> Manage security keys -> Sign-in data).
My passkeys are kept in my password manager. Many support them now: 1Password, Keeper, Dashlane, BitWarden, and I know KeePassX is working on support.
Sure it's not as secure as a hardware token but it's a nice sweet spot between convenience and security.
However I wish more platforms let me use TOTP and passkeys together for MFA. That way I don't need to put all my trust in a single password manager company. 2FAS with it's browser plugin gives a really slick experience and it backups to Google/Apple storage with a separate password to encrypt your OTP secret keys.
Bitwarden still doesn't support it on mobile, where it would probably the most useful, partially because Bitwardens auto fill on android is extremely unreliable, especially when dealing with two login pages (email then password).
Unfortunately I've also seen that a few times. There seem to be two common ways to get it wrong:
One is too-rigid modeling. Some sites explicitly only want to support passkeys as a single-factor authentication method, and then they don't go the extra length of also supporting non-discoverable credentials. (The only thing that would take is to optionally prompt for a user name in their login form, which almost all sites do anyway for legacy login methods.)
I do have empathy for sites wanting to not complicate their backend model too much, i.e. they only want to support two-factor authenticators, but many hardware authenticators these days support a PIN or biometrics! Some sites, I suspect, even outright exclude roaming (i.e. non-platform) authenticators, even though they do support discoverable credentials and user verification, i.e. everything that passkeys can provide too (albeit with limited storage capabilities), which is just sad.
The other is just due to outright bad practices: Some sites gate their WebAuthN implementation behind a user agent flag. Then they inevitably lack behind actual browser support, and in many instances the user agent alone won't even tell the full support story (now that browser might be using the OS-provided credential API, which can then delegate to a third-party password manager).
As often, Amazon wins the award for the worst possible UX here by
- Implementing WebAuthN as an alternative to password entry, rather than as an alternative second factor (which is the sane thing to do), which means I have to still provide my TOTP after providing my (dual-factor!) passkey. (Bonus: I can't use my passkey for password reauthentication, I have to log back out to get back to the screen where I can select one.)
- Excluding Firefox via user-agent sniffing (with a completely incoherent error message of "If you want to add a passkey, use a different cloud service account (example: Apple ID or Google account)" as a reasoning for why I can't proceed on Firefox
- Calling my USB hardware authenticator "iCloud Keychain", because I registered it via Chrome on macOS (?!)
- Requiring a PIN entry on an authenticator that supports it, despite not using any two-factor functionality semantically
I use all the same things as you, but PayPal doesn't use WebAuthn (that I can see). It's just 2FA hardware tokens, which should work fine (and I do get a prompt to use a USB key on Firefox).
Yes they do now! And it was firefox on mobile. Desktop firefox didn't support CTAP2 mode either except on Windows but it was fixed a few versions back (finally!)
There are some things I don't quite understand with passkeys.
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?
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.
> People say it's meant to replace login/password, not act as 2FAs.
They can, but they don't have to. It's up to the relying party (i.e. the website accepting them) to use them as a single-factor, two-factor, or just as yet another second-factor authentication solution.
Some websites make single-factor use contingent on the passkey's capabilities (e.g. user verification, only physical authenticators, only trusted-vendor physical authenticators through attestation etc). I believe Google does that and allows some users, based on these properties I believe, to use them as a single factor (the option is called "skip password when possible" in the account settings).
This is theoretically good for flexibility (one API allowing many use cases), but unfortunately quite confusing to users as the user experience can vary widely. One gripe I have with the API is that the default "user verification preference" is "preferred", which makes my hardware key prompt me for my PIN for every single authentication, even for second-factor usages that could just as well pick "discouraged" and use my as the other factor.
> 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.
That's correct – WebAuthN is intentionally a quite different model from GPG. That allows it to get by without key revocation, which would introduce a lot of complexity otherwise.
The specification allows something practically similar, though: Individual authenticators can be implemented almost statelessly, holding only a single root key that then derives (or unwraps) the per-credential keys from the key handle. It's a bit different from the federation you mention (all authenticators share a key rather than delegating signature privileges). But it's not commonly implemented, as far as I can tell.
I think for Google and Apple this is more of an agreed upon API to replace the multiple "login with X" buttons. Instead of having "Login with Google", "Login with Apple", "Login with Facebook", and "Login with GitHub", there is just one login button that uses your ecosystem of choice. That's the part that should make the process simple for users. Less choice.
In other words, it's to help you easily login to everything else. But your main account would still be protected by a password. Otherwise you wouldn't be able to replace a lost device.
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.
3rd party passkey provider support is possible on Android if:
- You are using Android 14
- Your manufacturer has added support for it (e. g. Oppo and OnePlus still haven't)
- If you want to use them in chrome, you need to enable the experimental feature at chrome://flags , search for "passkeys" and enable the feature for 3rd party (for brave just replace "chrome" with "brave"
Even with that, support may still be a bit buggy, such as:
- Chrome displaying the "Google Password Manager" logo instead of your password manager's one
- The app/website not understanding properly how to implement them and sending wrong values / sometimes invalid payloads
But let's hope this technology gains massive adoption, proper support and can help non-technical users benefit from increased security at (almost) no cost.
You can use any passkey provider app. I work at Bitwarden and we’re building mobile passkeys for android right now. We can do the e2e sync, but if you want you can always self host Bitwarden server and just use our clients app.
The BitWarden passkey dialog irks me because it makes me click the passkey I want, even if I have exactly one. It would be better to have a feature where I could specify "always use this passkey and don't prompt", since that's what I need 99% of the time.
My main beef with Passkeys is that there is no hardware attestation.
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.
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.
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 "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" or something along those lines, no ?
WebAuthn supports attestation, so passkeys must too. Usually I hear the opposite argument, that people don't want to use WebAuthn/passkeys because of attestation.
> WebAuthn supports attestation, so passkeys must too.
They can (it's optional, i.e. not a specification-"must"), but so far they don't. Apple explicitly unshipped attestation when they introduced keychain-synced Passkeys; I think Google also had attestation for a while on Android and did the same.
Requiring attestation was actually a way to opt out of passkey synchronization on iOS for that very reason, but Apple frustratingly just removed the option rather than leaving the choice to relying parties (websites). This makes their passkeys unusable for some regulated/sensitive use cases that did depend on attestation.
> Usually I hear the opposite argument
Different people have different needs and priorities. Authentication is a large surface with multiple actors and sometimes conflicting goals.
It's funny because in the last post on this topic everyone was complaining that the problem with passkeys is that they can't be transferred between devices like passwords can.
Unless you're trying to use them to enforce hardware DRM for you, why do you care that the user can't back them up? Lack of attestation is a good thing.
> Unless you're trying to use them to enforce hardware DRM for you
Oh FFS ! Not everything has to bubble down to the same old FLOSS claptrap you know !
> Lack of attestation is a good thing.
Had you read a few of the comments before posting, you would have learnt that regulated environments and sensitive use cases are two of many concepts that you would do well to think about before jumping on your "stick it to the man, no DRM !" bandwagon.
The Financial Sector is a low-hanging fruit example. If I'm trusting you to put on million-dollar trades, then I damn well want to know its you at the computer and not some Russian hacker who has has inevitably exfiltrated your credentials which were stored in software with Passkeys.
If I give you a Yubikey:
- I can force you to enter a password to "arm" it for use every time, no caching
- I can force you to physically touch it to execute the transaction
- Through hardware attestation I can know it is your Yubikey that I gave you
- I can force it to lock the key if the wrong password is entered too many times
- If you loose your Yubikey, I can kill access
- Many other things...
Time and time again software has shown us that you cannot trust it with secrets. That's why HSMs exist, that's why Yubikeys exist.
The modern world is a scary place in terms of security, hardware attestation is a CRITICAL part of the security onion.
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.
A colleague summarized our latest Passkey issues showing the ecosystem remains fragile for enterprises:
At pico.sh we are developing a completely different type of passwordless authentication all leveraging what developers are already familiar with: SSH keys.
No passwords, no JWTs, no bearer tokens, no complicated webauthn, and no passkeys. All we need is an SSH keypair.
Readit News
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.
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.
You have to display the password prompt for invalid accounts to avoid enumeration without webauthn too...
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. )
Authentication which requires multiple independent mechanisms is rarely a user benefit though; it is the result of regulatory requirements or corporate risk aversion.
If companies are adopting passkeys, it likely means risk that they were formerly solving with a second factor (like weak/passive phishing resistance or credential reuse) are solved via baseline passkey provider behavior.
> 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.
You can protect this via the PIN of the security key, to prevent third parties who get access to your key (such as through coercion) seeing which websites you have accounts on.
They are also good for enterprise deployments, where you can justify 2 (or 3) keys per user, and where you have a dedicated IT team to take care of account resets.
But resident keys for general website logins are a terrible idea. As other posters have already pointed out, the relevant security keys have a fixed number of key slots. Current best-of-breed hardware can store 25 resident keys. With only a small fraction of websites using WebAuthn, that limit is not an immediate concern - but considering the average user has about 100 online accounts[0], those slots will run out. Now consider that to have them be secure, the keys really can't be exportable. And in order to account for hardware failures and/or misplacements, you'd need a minimum of two such devices enrolled for each account.
The most depressing part of this all is that while passkeys are under the hood FIDO2 credentials, and their communication protocol is the same as with hardware devices, having a passkey support can indeed rule out physical devices. As the article points out, the transport specifier is different, and there is nothing that prevents an implementation to flat out reject anything other than "internal".
0: https://tech.co/password-managers/how-many-passwords-average...
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.
Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).
Finally, only a tiny part of the population uses dedicated hardware tokens, whereas pretty much all popular password managers supports or will support Passkeys (Apple Keychain, 1Password, whatever the Chrome password manager is called, Samsung Pass, etc.).
So, it’s not surprising that hardware tokens are tested less these days.
(I don’t think that is a good, just trying to speculate on the reasons.)
Chrome allows you to see stored resident keys and delete individual resident keys on any hardware token which supports CTAP 2.1. (to be fair, it is a bit hidden: Settings -> Privacy and security -> Security -> Manage security keys -> Sign-in data).
https://www.token2.com/shop/category/pin-release2-series
Sure it's not as secure as a hardware token but it's a nice sweet spot between convenience and security.
However I wish more platforms let me use TOTP and passkeys together for MFA. That way I don't need to put all my trust in a single password manager company. 2FAS with it's browser plugin gives a really slick experience and it backups to Google/Apple storage with a separate password to encrypt your OTP secret keys.
[0]: https://keepassxc.org/blog/2024-03-10-2.7.7-released/
One is too-rigid modeling. Some sites explicitly only want to support passkeys as a single-factor authentication method, and then they don't go the extra length of also supporting non-discoverable credentials. (The only thing that would take is to optionally prompt for a user name in their login form, which almost all sites do anyway for legacy login methods.)
I do have empathy for sites wanting to not complicate their backend model too much, i.e. they only want to support two-factor authenticators, but many hardware authenticators these days support a PIN or biometrics! Some sites, I suspect, even outright exclude roaming (i.e. non-platform) authenticators, even though they do support discoverable credentials and user verification, i.e. everything that passkeys can provide too (albeit with limited storage capabilities), which is just sad.
The other is just due to outright bad practices: Some sites gate their WebAuthN implementation behind a user agent flag. Then they inevitably lack behind actual browser support, and in many instances the user agent alone won't even tell the full support story (now that browser might be using the OS-provided credential API, which can then delegate to a third-party password manager).
As often, Amazon wins the award for the worst possible UX here by
- Implementing WebAuthN as an alternative to password entry, rather than as an alternative second factor (which is the sane thing to do), which means I have to still provide my TOTP after providing my (dual-factor!) passkey. (Bonus: I can't use my passkey for password reauthentication, I have to log back out to get back to the screen where I can select one.)
- Excluding Firefox via user-agent sniffing (with a completely incoherent error message of "If you want to add a passkey, use a different cloud service account (example: Apple ID or Google account)" as a reasoning for why I can't proceed on Firefox
- Calling my USB hardware authenticator "iCloud Keychain", because I registered it via Chrome on macOS (?!)
- Requiring a PIN entry on an authenticator that supports it, despite not using any two-factor functionality semantically
That's WebAuthN too (if you mean USB-connected FIDO tokens).
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?
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.
They can, but they don't have to. It's up to the relying party (i.e. the website accepting them) to use them as a single-factor, two-factor, or just as yet another second-factor authentication solution.
Some websites make single-factor use contingent on the passkey's capabilities (e.g. user verification, only physical authenticators, only trusted-vendor physical authenticators through attestation etc). I believe Google does that and allows some users, based on these properties I believe, to use them as a single factor (the option is called "skip password when possible" in the account settings).
This is theoretically good for flexibility (one API allowing many use cases), but unfortunately quite confusing to users as the user experience can vary widely. One gripe I have with the API is that the default "user verification preference" is "preferred", which makes my hardware key prompt me for my PIN for every single authentication, even for second-factor usages that could just as well pick "discouraged" and use my as the other factor.
> 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.
That's correct – WebAuthN is intentionally a quite different model from GPG. That allows it to get by without key revocation, which would introduce a lot of complexity otherwise.
The specification allows something practically similar, though: Individual authenticators can be implemented almost statelessly, holding only a single root key that then derives (or unwraps) the per-credential keys from the key handle. It's a bit different from the federation you mention (all authenticators share a key rather than delegating signature privileges). But it's not commonly implemented, as far as I can tell.
In other words, it's to help you easily login to everything else. But your main account would still be protected by a password. Otherwise you wouldn't be able to replace a lost device.
I just tried and all I need to provide is the email ID and passkey. You need to use the "Try another way" option.
If implemented correctly user shouldn't even need to provide the user ID at all.
- You are using Android 14
- Your manufacturer has added support for it (e. g. Oppo and OnePlus still haven't)
- If you want to use them in chrome, you need to enable the experimental feature at chrome://flags , search for "passkeys" and enable the feature for 3rd party (for brave just replace "chrome" with "brave"
Even with that, support may still be a bit buggy, such as:
- Chrome displaying the "Google Password Manager" logo instead of your password manager's one
- The app/website not understanding properly how to implement them and sending wrong values / sometimes invalid payloads
But let's hope this technology gains massive adoption, proper support and can help non-technical users benefit from increased security at (almost) no cost.
Disclaimer: work for a Password Manager
Patiently waiting for passkey support on Bitwarden iOS to replace all my passwords everywhere.
Do you guys have any rough idea how far away you are from launch? Is it weeks? Months? Quarters?
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.
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.
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 "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" or something along those lines, no ?
They can (it's optional, i.e. not a specification-"must"), but so far they don't. Apple explicitly unshipped attestation when they introduced keychain-synced Passkeys; I think Google also had attestation for a while on Android and did the same.
Requiring attestation was actually a way to opt out of passkey synchronization on iOS for that very reason, but Apple frustratingly just removed the option rather than leaving the choice to relying parties (websites). This makes their passkeys unusable for some regulated/sensitive use cases that did depend on attestation.
> Usually I hear the opposite argument
Different people have different needs and priorities. Authentication is a large surface with multiple actors and sometimes conflicting goals.
Oh FFS ! Not everything has to bubble down to the same old FLOSS claptrap you know !
> Lack of attestation is a good thing.
Had you read a few of the comments before posting, you would have learnt that regulated environments and sensitive use cases are two of many concepts that you would do well to think about before jumping on your "stick it to the man, no DRM !" bandwagon.
The Financial Sector is a low-hanging fruit example. If I'm trusting you to put on million-dollar trades, then I damn well want to know its you at the computer and not some Russian hacker who has has inevitably exfiltrated your credentials which were stored in software with Passkeys.
If I give you a Yubikey:
Time and time again software has shown us that you cannot trust it with secrets. That's why HSMs exist, that's why Yubikeys exist.The modern world is a scary place in terms of security, hardware attestation is a CRITICAL part of the security onion.
Deleted Comment
A colleague summarized our latest Passkey issues showing the ecosystem remains fragile for enterprises:
Fragile Passkey Ecosystem for Enterprises https://news.ycombinator.com/item?id=39742107
No passwords, no JWTs, no bearer tokens, no complicated webauthn, and no passkeys. All we need is an SSH keypair.
We have a demo if you are interested in learning more: https://pico.sh/tunnels