Passkeys – Under the Hood
research.kudelskisecurity.com
research.kudelskisecurity.com
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...
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?
[1] https://github.com/fido-alliance/how-to-fido/issues/16
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.
Its replacement is $25, which is expensive enough to be an issue for poor people.
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. )
But I agree it's much simpler to achieve that just by using a password manager.
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...
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.
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.
That's WebAuthN too (if you mean USB-connected FIDO tokens).
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).
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.
This is because SSH doesn’t have a centralized RP model that’s kind of implied in FIDO and WebAuthN for non-resident keys.
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.
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.
https://keepassxc.org/blog/2024-03-10-2.7.7-released/
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?
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.
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
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.
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.
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 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.
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?
I'm eager to give it a try.
Unfortunately that API doesn't seem to be wired to anything in the app yet, so selecting it inevitably fails.
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)"?
- 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
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.
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).
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.
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...
The modern world is a scary place in terms of security, hardware attestation is a CRITICAL part of the security onion.
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...
> 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.
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
That way if my wife and I can use her Amazon account.
Can the same paradigm be grafted to pass-keys/webauthn?
Maybe a useful flow could be
You can log in with any of the following:
a) passkey b) email and sms and password verification c) customer service
Its not 100% air tight; but it seems better than the current state of affairs.
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...)
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.
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.
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.
Firefox does support them on Windows and macOS, just like physical cross-platform authenticators (i.e. “Yubikeys”).
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.
No, they don't. Apple vends an API to allow third party password managers to hook into Safari and other apps to save and provide passkeys.
I use 1Password on Windows and iPhone to use my passkeys between Firefox, Chrome, and Safari.
https://developer.apple.com/passkeys/
https://developer.apple.com/documentation/authenticationserv...
Looks like Chrome on Android has flagged support for this (not enabled by default) so presumably thats coming soon as well.
https://blog.1password.com/save-use-passkeys-android/
https://1password.community/discussion/143903/how-do-i-use-p...
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 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.
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.
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.
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.
I've been using Passkeys for many weeks now. Bitwarden can provide its own implementation as well (albeit it being a bit "hacky")
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.
- When do users still need their password, and when is a passkey enough? Can they safely forget their password?
- How do they switch from iOS to Android and vice versa without losing access to all accounts?
> Scanned my face as I always use to open my phone. That site is now authenticating with my face.
- Can I login on my friend's phone using my face? Yes, because it's authenticating my face, right?
- What happens if I lose access to my iCloud or Google account? How do I get my passkeys back?
- 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?
And please don't use any assumptions you might have about these flows from your background knowledge as a developer.
No. Don't forget your password. Why would you?
> 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.
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)
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.
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.