> 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?
This is why they're pushing passkeys in phones' secure element with cloud account sync: getting people to keep a separate set of hardware keys is nigh impossible at scale.
Sure, but why not preserve the option for people to use hardware keys?
Unfortunately, both the FIDO and WebAuthN working groups seem to be dead-set on making the hardware authenticator use case as painful as possible [1] [2] [3].
I just don't get it. Why even try to pretend that WebAuthN is a single API for both use cases when all stakeholders in charge seem to have given up on one of them?
Most modern smartphones support contactless smartcards (a.k.a. "NFC"), which can be used as FIDO credentials. It should be possible to produce these for around $2 at scale.
They wouldn't work at computers, unfortunately (not even with an adapter, since desktop browsers and OSes don't expect to speak FIDO-over-ISO-7816-over-CTAP-over-USB), but with QR-based cross-platform flows now part of the specs, phones could pretty straightforwardly serve as readers for other devices.
If large issuers of ISO-based smart cards (e.g. banks or government authorities for biometric ID cards and passports) could be convinced to just throw a FIDO implementation on there (there's open-source ones available!), people could even use the cards they already own.
Yubikey used to sell a simple Webauthn-only key for $10-$15. USB-only, no NFC or anything. It was blue instead of the standard black. That one was essentially killed when Passkeys became popular, because it didn't support resident keys. I believe some companies (Google? Github?) were giving them away for free.
Its replacement is $25, which is expensive enough to be an issue for poor people.
Thanks, I'll look into that product. Less costly, but still far from the $2 scenario. If hardware keys got to a super low price point, or even handed out for free or bundled with new phones or PCs, I image lots of people would prefer them over passkeys.
I am a yubikey user, but they are a terrible option for a normal person. Losing a hardware key means being locked out from all your accounts for real, and if cryptography taught me one thing it's that people are not responsible enough to manage their own keys (keep a backup key up to date, print recovery codes, etc)
> 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".
With Yubikeys there's also the option of using the GPG smart card functionality for SSH keys. It's quite a bit of a hassle client-side, but it's completely transparent to the server.
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).
I don't think discoverable credentials on hardware authenticators are a good default pattern (even though requiring(!) resident/discoverable keys is the suggested behavior [2] by the FIDO alliance!?)
They have their uses for special use cases for authentication against local or otherwise non-synchronized relying parties or as a component of authentication protocols that aren't a good fit for native WebaAuthN (like SSH), but a regular old website can just ask me for my user ID (which is my email address in 99% of all cases).
Unfortunately, there isn't [1] a way to say (in WebAuthN API terms) something like "give me a discoverable credential if you have unlimited storage, otherwise nevermind", so as far as I understand, a relying party can only say "preferred" (taking up a scarce slot on a HW authenticator) or "discouraged" (making a platform credential non-discoverable needlessly, except on platforms that ignore that flag anyway like Apple/iCloud Keychain).
As an aside, that issue [1] having been closed without any accomodation for that use case fits with my anecdotal observation of the WebAuthN working group having largely pivoted towards the "Passkey paradigm". Hardware authenticators somehow don't feel like a first-class API concern anymore.
I'm kinda hoping Yubi come out with a version 6 with many more "passkey" CTAP2 slots too. Because I don't only use FIDO functionality but I heavily use the OpenPGP slots as well. Not for email but for other things (file encryption, password manager, SSH). Not planning to change any of that to fido any time soon either.
Yeah, but without resident keys you’ll have to carry a file containing the key handle around with you from computer to computer (where you want to use the Yubikey-resident SSH key). And if you ever lose the file, your key is lost too!
This is because SSH doesn’t have a centralized RP model that’s kind of implied in FIDO and WebAuthN for non-resident keys.
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).
Bitwarden doesn't have support in apps, but you can get passkey support in Firefox by installing the Bitwarden addon.
I would've preferred more integration here (because unlocking the app vault doesn't unlock the addon vault, for example) but I think this is just because of the lack of proper APIs for this kind of thing. Android's auto fill API is using the standard system API, but the system API clearly isn't designed for the "enter your username, hit next, then enter your password" flow.
This post prompted me to give it a try at webauthn.io.
Passkey support is disabled by default, so you have to enable it in the settings for the browser extension. After that, the UI seems reasonable enough. It creates an entry with a "Passkey" tag, where the Password field is empty, and the credentials are stored as additional attributes on the Advanced tab.
One thing I'm not sure about: although the extension has a setting to fall back to the browser's own passkey support, when I dismissed the KeePassXC prompt, I did not get a prompt from Firefox.
Thank, I hadn't noticed that, I thought I had to wait for the extension to be updated after the announcement from KeepassXC.
> After that, the UI seems reasonable enough.
I tried it on webauthn.io and I'm wondering if there's a point in showing a prompt on every login attempt, if passkeys are phishing proof. Why not just allow the login right away? Maybe show a notification that it happened, but why wait for user confirmation?
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.
This has been annoying me as well: WebAuthN even provides metadata that lets authenticators know which credentials they're willing to accept, so at least in that case (usually the flows where you have to enter a username), auto-selection should be possible.
With discoverable credentials (which Passkeys by definition are), i.e. the flows where you don't even enter a username and the website learns it from the selected passkey, I don't think there's a way around a key selection process, but the UI can definitely be improved to distinguish the two.
Maybe something like "website XYZ is trying to verify your account 'username' – is that ok?" vs. "website XYZ wants to authenticate you – which passkey do you want to present to them (if any)"?
I'm already seeing Bitwarden as an option for Passkey authentication on iOS! Apparently the app already exposes itself to iOS as a WebAuthN backend (or the API is the same as that used for password managers).
Unfortunately that API doesn't seem to be wired to anything in the app yet, so selecting it inevitably fails.
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.
This might be being reconsidered; I don't have the full details but I've seen some talk about attestation being expanded to handle roaming keys as well.
I think that's a mistake -- I think there are a lot of security and UX considerations around roaming keys that make attestation not suitable: For example, what happens when a user moves between ecosystems and finds out after the fact that their new ecosystem isn't supported? Also does attestation for an ecosystem and not just for a device actually offer any strong security or phishing guarantees? Apple supports sharing passkeys with contacts, so what phishing protection are you actually getting here?
I'm a little bit skeptical of attestation in general, but there are scenarios where some regulatory bodies might really want it, and many of these specific concerns don't exist for device-bound keys, and you do actually get some strong security guarantees from them, so attestation at least makes a bit more sense there. I look at a company asking for attestation for device-bound keys and think, "yeah, that makes sense, you want a strong security boundary around the key."
But my point isn't to argue one way or another, just to point out that, yes, keychain-synced passkeys on devices like iOS don't support attestation right now. But I don't know if that's going to be the case in the future or how that will change when certification starts ramping up.
> 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.
I'm too far out from the tech to speak confidently about it and I'm sure there are considerations I'm not aware of, but it really seems to me from the outside that a key being synced or device-bound should have been an attribute of the passkey and not like an entirely separate system. I know there are considerations with hardware tokens and resident key limits, but I also suspect part of this is that roaming keys were a later addition, my understanding is that they were relatively controversial when first proposed and so maybe that led to them kind of evolving separately? I'm just guessing though. It is very weird that iOS requires passkeys to be roaming keys.
That's (anonymous) device attestation, not authentication key/credential attestation. Two completely different use cases.
One prevents against spam/bots, the other prevents against users getting phished/scammed into registering an attacker's credential on their account (or using an insecure credential that can later be phished/hacked, e.g. because it's not hardware-bound and easily exportable).
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.
> 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.
In such a high-value environment, you could buy the YubiKey, provision an account for me registered to it, then give it to me. That would give you the assurance you want without needing remote attestation. Also, if Russian hackers had enough access to my computer to steal my software passkeys, couldn't they just wait for me to start a valid session with my YubiKey and then use that session to do whatever they wanted?
> - 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...
Those are downsides, not upsides, because of the mixing of "I" and "you". I should be able to decide my own risk tolerance levels for access to my own accounts. You shouldn't get to decide them for me.
> 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.
Sure, that's a good argument for hardware secret storage. But not for attestation. It's a good thing that I have the ability to use HSMs and YubiKeys for access to my accounts, but if I don't want to, other people shouldn't be able to force me to.
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.
This is completely up to the relying party (i.e. website) and definitely possible. WebAuthN makes explicit accomodations for a user having multiple credentials registered on their device, and they can even be of different types (e.g. you can have one shared hardware authenticator, your iCloud Keychain passkey and your wife's Bitwarden-stored passkey all registered on the same account).
I have multiple passkeys registered with some sites, e.g. Github (and conversely I use many sites that only allow me to associate a single phone number, which I better never lose access to...)
This seems like the standard to allow multiple passkeys, which makes sense... the passkeys are device specific, (not considering synced ones like bitwarden)... So if i login on my windows pc with a passkey i also want to be able to login on my iphone with a passkey, if they didn't support multiple passkeys per account this wouldn't be possible, even without taking into account different people in a family having a passkey.
Passkeys are very much intended to be synced by various WebAuthN stakeholders, for better or worse.
But yes, any site that e.g. wants to support roaming authenticators ("Yubikeys") needs to support multiple credentials, or recovery from a device loss gets very tricky.
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).
There are two problems:
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.
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.
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.
The problem isn’t the lack of an API, but rather the default being to store passkeys in an unexportable format in Apple’s or Google’s password safes.
Unsophisticated users are very likely to inadvertently lock themselves into their current platform with passkeys. Passwords can be copy-pasted over to a new password manager, worst case.
Apple's is also not un-exportable. I've twice exported my password database to try other password managers.
Apple's built-in is now approaching the level of a full password manager rather than just keychain sets. Entries can be mapped to multiple sites/hosts, it supports TOTP, and shared sets. Even "plays well" with third party managers but I wouldn't recommend that, it gets confusing.
> Apple's is also not un-exportable. I've twice exported my password database
Well, have you tried exporting a passkey? Passwords and passkeys are not the same thing in Apple's implementation, and I don't think there is a way to export the latter by design.
I think they can be shared via AirDrop these days, but that doesn't provide a migration path out of their walled garden since I think that process is mediated by Apple somehow, i.e. it's not just a JSON-encoded private key or anything like that.
Unfortunately Apple have been pretty bad about updating their "Apple Platform Security" document, which is where they'd normally share such details, so I haven't been able to figure out how "passkeys over AirDrop" actually work under the hood and whether there's a path to cross-vendor migration there.
> I've twice exported my password database to try other password managers.
Have you done that on just an iPhone? Last I checked you need a Mac. So iPhone users have to by another Apple product to leave the Apple ecosystem in way that doesn't require you to unlock your password settings multiple times to transfer each password.
> Firefox doesn't even support this stuff properly yet
What OS are you referring to? It works perfectly on macOS now, and I believe Windows has been supported even longer.
> 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 wouldn’t call this a comparable situation. Passkeys are very interoperable (save for sites doing incompetent browser sniffing, “sorry, Firefox does not support passkeys” etc.), but there is a factor of platform lock-in.
Not great, but much more feasible to address since any fix can be done purely on the implementation backend without changing the API.
Not sure it's that hard to explain the basics. Passkeys are like very big passwords that password manages store for you, only with extra features. I don't think you need to touch on the public key encryption side of it.
Big Tech don't insist on their solutions, they just default to it which I think is fair.
Also WebAuthN is passkeys from what I understand. Not a previous effort.
That about summarizes the problem. It's definitely related to webauthn. But not the same thing. Which is why Firefox supports one but not the other (yet, I believe they are working on it). You could do webauthn without a hardware dongle but nobody seems to want to implement that until passkeys. Now your phone effectively becomes the hardware dongle. And if you then get rid of passwords, you are down to one factor. You had better not lose your phone, just saying.
Big Tech insists on their version of the tech which makes them the center of your universe, at the cost of their competitors and their users. Which is why we still have password logins everywhere. The solutions to move away from that have been around for some time. But big companies can't agree with each other on how to do this such that they don't lose users to each other. So, MS pretends to be the center of your world. So does Google. And Meta. And of course Apple. And a few others. And when you setup 2FA you are guided to use the Google Authenticator. Which of course annoys the hell out of competitors who then do something else or only reluctantly support 2FA or come up with some wacky scheme to do something with SMS.
Passkeys look like they are more of the same so far.
Passkeys are just a catchy (or confusing, depending on who you ask) name for a specific type/profile of WebAuthn authenticator (discoverable platform authenticators to be precise).
Firefox does support them on Windows and macOS, just like physical cross-platform authenticators (i.e. “Yubikeys”).
> And if you then get rid of passwords, you are down to one factor
I agree this is a bit of a shame. I'm hoping platforms support using passkeys with other factors.
> You had better not lose your phone
You can sync passkeys between devices and backup to a cloud.
> big companies can't agree with each other on how to do this
This was the case 18 months ago, I'm not so sure it is anymore. On my Google account I can setup a passkey passwordless login with a 3rd party password manager. I can do the exact same thing with my Microsoft account. There are still rough edges, for example to setup the passkey on MS I had to select the method "Use your Windows PC" but it all works.
Is it? While I'm a developer I have zero knowledge about passkeys. (haven't even read the linked article. Which is usually not a badge of honour, but in this case ensures that I'm as much an end user as one can be.)
I logged in with some website on my phone. The website asked me if I want to use passkeys and told me that means I can log in using my fingerprint/face id. I clicked yes. Scanned my face as I always use to open my phone. That site is now authenticating with my face.
Didn't feel like it was hard to explain to me. It felt all quite straightforward to be honest.
> How do they switch from iOS to Android and vice versa without losing access to all accounts?
Use your password. Or if you can't use it use the "I forgot my password" process.
> Can I login on my friend's phone using my face? Yes, because it's authenticating my face, right?
They can try if they have this question. I wouldn't expect it to work because it is my phone who knows my face and not the website. But if that is too much thinking for an unsophisticated user they just try it and see that it doesn't work.
> What happens if I lose access to my iCloud or Google account?
You use the "Forgot my password" process of the site.
> Why does website X say "your browser does not support passkeys", but it works on website Y? Is Firefox really bad? Do I have to switch to Chrome?
As an unsophisticated user my phone have none of these things.
> please don't use any assumptions you might have about these flows from your background knowledge as a developer.
That is a bit like asking to not think of a pink elephant. But also I haven't thought of any of these questions as I was enrolled using my passkey. (Nor did I think about these questions ever since even once.) So I would suspect worrying about these questions is not the primary reason why people use or don't use passkeys.
Because passkeys are replacing my password, right? Also, I think if I don't ever have to provide it on a regular basis, I'll eventually forget it.
> Use your password. Or if you can't use it use the "I forgot my password" process.
Why should I use passkeys then if I sometimes need my password anyway?
> They can try if they have this question.
Ok, I tried it and it doesn't work. Is that my fault or the site's? I'm confused – will your support be able to help me out?
> Nor did I think about these questions ever since even once.) So I would suspect worrying about these questions is not the primary reason why people use or don't use passkeys.
These concerns aren't about people not using passkeys, quite the opposite: They're about sharp edges that people usually only hit months or years into using a new authentication method.
> These concerns aren't about people not using passkeys, quite the opposite
The person who I responded to said:
“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.”
They clearly think “hard to explain” is the reason why they are not more popular. That is what i responded to. You are making an orthogonal point about trickyness of account recovery. (One i largely agree with, but has nothing to do with the ease of explaining passkeys)
I'm not sure "fall back on the existing method" is really an explanation though. It's like saying, "stick shift is easy to explain, whenever you're confused just switch back to standard."
Passkeys are meant to be a password replacement. "Use your password" can't be the answer to "how do I do X with passkeys"? We're talking about onboarding people onto a separate system, they're going to want to know why they're being asked to use two systems simultaneously.
Platform operators do think about support load and edge cases like the ones I've mentioned, and so to them these are obstacles to deploying passkeys. "How can I explain passkeys to my user?" covers more than just the happy path.
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.