I'm just confused about the "something-you-know" aspect of this. From my understanding, in the US you can be legally forced to give your fingerprint, face scan, probably your retina scan, maybe your voice identification... these are all "things you have", more akin to "username". But a password is the "thing you know", the thing they can't take from you (discussions of torture and AI mind-reading aside).
So is the idea there that that basically goes away with passkeys, and that your only "thing-you-know" protection is the x-digit passcode you punch into your phone?
> fingerprint, face scan, probably your retina scan, maybe your voice identification
Technically, those are "things you are", not "things you have". A Yubikey would be an example of a "thing you have".
I think the ideal is that you're supposed to use a hardware key that uses a biometric like a fingerprint to unlock it. Then the passkey itself is the "thing you know", the hardware key is the "thing you have", and the fingerprint is the "thing you are".
But in practice, that's pretty onerous, so the passkey implementation being discussed eases up on those requirements a bit.
A passkey is never a "thing you know." It is a "thing you have access to, which mostly behaves like a 'thing you have' but also your OS provider probably has it if they want it."
Well, we're deep into semantics now, but I think the passkey is "something you know". That you've chosen to offload your memory onto a device doesn't really change that.
But, honestly, this is a point of little importance. Almost all of the "something you..." categories are only a rough guide, and most items can arguably fall into more than one of them.
That's not really deep into semantics if it's the whole point. Something you know is by definition not externalized, and thus has a different type of security.
If a passkey is something you know then you are using a failed implementation. A fido/authn device is supposed to be able to attest to never having let the private key out, even with a relaxation to passkeys it should at least be sending it to another device that can attest.
That last part is huge: the FIDO-2/WebAuthn protocol includes the hostname so there’s no way to have a challenge from server A get a response which could be used on server B. That alone is worth the switch since so many people get painfully phished into entering an important password on the attacker’s server.
passkeys are often 2 factors but not necessarily something you know, examples:
- with macbook fingerprint sensor: something you have (private key on your device) and something you are (fingerprint)
- with yubikey without fingerprint: something you know (passcode, hopefully required) and something you have (private key on yubikey)
- with yubikey with fingerprint sensor: something you are (fingerprint, falling back to passcode which is something you know) and something you have (private key on yubikey)
But that's the whole point - yubikey with fingerprint, or any combination of things that exclude "something you know", opens you up to a whole set of vulnerabilities. Like "legal snooping"; that can't be done if you're protected with "something you know".
The iPhone very particularly insists on a password/passcode if you trigger the emergency call screen, so that you can do that quickly and they can't force you to unlock biometrical.
Just because this is a common misunderstanding of passkeys, I'm going to state it again here: passkeys don't have to be locked to a hardware chip inside your device in order to work. It is entirely possible to have use passkeys only in software (shameless plug to the passkey manager I'm building, https://bulwark.id), and that is most likely the way that most people will interact with them.
I think it's unfortunate that Apple and Google are the ones who are most visible in the passkey space because it gives people the idea that passkeys are a locked-down authentication mechanism when they aren't.
>that is most likely the way that most people will interact with them
i admire your confidence in your product, but i'm pretty sure the way most users will interact with passkeys is the first-party workflow that their devices promote, and not third-party tools.
Last time I looked into your implementation, it looks very neat, but I would like to store each passkey to a file and encrypt with GPG. I use https://www.passwordstore.org/ like mechanism to store all my passwords.
This is something that would be very nice to support, and saving to just a local file and allowing users to use their own storage mechanisms is definitely an intended use case. Right now it stores the entire vault encrypted on disk, but I would like to be able to store passkeys in a standard format (ideally supported by multiple managers) and then allow users to do whatever they want with them.
Generally, the idea is that the private keys are stored on a TPM chip so they cannot be exported for security reasons, similar to a YubiKey or a crypto wallet. I know Apple and Google are looking into trying to allow users to somehow export these keys elsewhere, but I'm uncertain how easy that will be or what tradeoffs there will be. I'm skeptical that Apple and Google will try to make it too easy since they benefit from user lock-in, but I would be happy to be proven wrong.
Apple's existing password manager (which is what surfaces passkey management) lets you export and import the database as a CSV file, same as Google and many others. I suspect the biggest missing piece is an agreement on an interoperable format - likely one that would also be interoperable for password and TOTP exchange as well.
As far as I can tell both Google and Apple have a mechanism to export the key so you can replicate the same key to another device. I run into this same situation with "HSM clusters" sold in enterprises where I don't really understand how people can claim with a straight face that you can't export the key to another device when they just explained to me that they export the key to another device.
That is not Apple’s stated design at all. If you read Apple’s passkeys security document, it claims that the private keys are synchronized with iCloud and are recoverable following the loss of all devices. Non-exportable passkeys using the TPM is an HN myth.
The private key is both kept in your phone’s Secure Enclave and stored in iCloud, so strictly speaking the implementation isn’t hardware-bound in that case.
But I think the intended point is something more practical: can you, as a user, export the passkey to be shared on your non-Apple laptop, phone, etc? And maybe I’m mistaken, but I’ve been under the impression that you cannot.
I'm the author of the blogpost. You are spot on, Passkeys are exportable so the private key ends up both on iCloud and the Enclave/authenticator.
My understanding is that there's chatter about cross-vendor synchronization of passkeys but nothing concrete yet.
Meanwhile Apple allows people to share Passkeys via AirDrop (Settings > Passwords - select the passkey you want and click the "Share" icon to send it over Airdrop) so it should be possible with some effort to obtain the private key with something like this: https://github.com/seemoo-lab/opendrop. Haven't done extensive testing yet though, so I can't confirm.
Would love to hear if anybody knows more about how the sharing via AirDrop is implemented/protected.
Given it sync from iCloud, you probably could export with enough prying at the MacOS Keychain app, but exporting them out is not a supported use case yet.
I'm the author of the SlashID blogpost. You are right, the WebAuthn standard doesn't provide any guarantees on the authenticator storage security hence passkeys (and WebAuthn creds) can be stored in anything that speaks CTAP2.
Is there any company actually providing anything resembling emergency access for Passkeys? A critical feature of password vaults for me is the ability of my heirs to get access to my passwords when I am incapacitated or dead. I can't print out my passkeys and store them in a safe, nor does there appear to be any system for allowing someone access to my passkeys.
> I can't print out my passkeys and store them in a safe, nor does there appear to be any system for allowing someone access to my passkeys.
In essence it's possible - some app that exports the passkey's private key in some standard format as a QR code [per passkey], ready to be re-imported, but such import/export mechanisms haven't been made yet.
In practice, as long as your heirs have access to your email, they should be OK. Password reset flows still work with passkeys.
You also should be able to back up passkeys onto a flash drive and encrypt them with a strong password. I don't think there's a good tooling for this right now, though. On macOS you'll need to go to Keychain Access and manually export the keys.
(I store everything important in an encrypted container, with the 128-bit recovery code printed on paper and stored in a safe deposit box)
> I can't print out my passkeys and store them in a safe, nor does there appear to be any system for allowing someone access to my passkeys.
Recovery is handled differently depending on who you are using to sync your passkeys. Apple has a great recovery story. iCloud Keychain supports both a "recovery key" and "recovery contacts".
This looks good, but it's not clear that it would actually work in this scenario. The "Recovery Security" section of the first document is good, but it requires knowledge of some combination of the phone password, an "iCloud security code", possession of the SMS number for the user, etc.
The latter two links are good, but both only refer to recovering access to an iCloud account, they don't talk about further access to escrowed iCloud keychains.
> The Client Device should sign the sent public key with its own Attestation Certificate. The certificate is used to attest to the manufacturer and its capabilities.
A nitpick: should is a value judgment here. Quite a few of us would rather they do not, to avoid websites taking advantage of this to require specific proprietary hardware to authenticate.
Thankfully my understanding is that Apple's passkeys do not provide attestation, which is likely to make this kind of hardware requirement uncommon.
Apple has their own anonymous attestation format[1] that some (unclear which?) of their WebAuthn authenticators support.
In principle the relying party could use this to verify the authenticity of the authenticator back up to Apple's WebAuthn root CA[2]. In practice, I'm not sure if that attestation is included by default (or whether significant portions of users opt out of it, when prompted by their browser).
Yes, I consider attestation a bit of a poison pill, personally. I'm very ambivalent about passkeys as it is, if attestation throws a monkey wrench into the works, my ambivalence would become active resistance.
It makes sense in an enterprise context, where the company might want to make sure no employee clones a client device key. In that case, they would require remote attestation to authorize only private keys living in secure elements (and thus less accessible to the employee).
Apparently these are unsupported on Linux? When I try to use my brand new Yubikey 5 Nano with Chrome or Firefox on the webauthn.io demo, it works great. However when I try on passkeys.io, it just hangs at the "You can connect and authorize [a security key] now" prompt.
I've been working on passkeys for about a year now, and from my experience passkey support is fairly inconsistent. Every website+browser+OS combination can do things slightly differently or ask for a different set of features from the authenticator (some require PIN support, some require certain flags, etc), so the experience can be a bit buggy. I imagine that as passkeys get more common the support from authenticators and platforms will improve as it becomes more standardized.
A note on attestation, since that's a part of Passkeys (and Webauthn) that's frequently misunderstood: WebAuthn has a broad understanding of "attestation," including "self attestations"[1] and no attestations at all[2]. To the best of my knowledge, Passkeys do not impose any further constraints on attestations, meaning that compliant authenticators don't need to send any attestation at all.
Relying parties can of course reject authenticators for any reason, including for not having an attestation statement (or not having one from a particular vendor). In practice, I'm not aware of any major public service that does that: actually verifying vendor attestations introduces yet another PKI, and has dubious security benefits outside of corporate (meaning fixed hardware) contexts.
In other words: while understandable, I think a lot of concern about vendor lock-in and lock-out are pretty overblown. There's no indication that services like GitHub will even find attestation handling feasible, much less desirable.
My worry about attestation isn't that it will lead to vendor lock-in, it's that some services may choose to reject authenticators that don't attest that they're storing the keys in TPM or similar.
In case clarification is needed: Pass is GPL licensed, open source software.
GPL is not the same as the GNU Project. The former is a license; the latter is collaborative project composed of multiple software packages and their respective contributors, typically using the GPL license.
I fail to see how the authorship of a project makes something (non)proprietary — in all definitions I’ve seen, it’s the terms under which software is permitted to be shared that determines if something is proprietary or not.
On my Windows laptop, I was able to set up a passkey with Windows Hello [a fingerprint swipe] to get into a secondary Google account that really only exists to store [pages of] coloring books (PDFs)
I'm admittedly ignorant in this domain; but I thought it was interesting that my built-in Chrome passwords were, and still are, locked behind the Windows Hello pop-up and now I could theoretically use that same mechanism to sign in to a google account all together.
The answer is probably in this article but I just don't understand; I'd love to know why Windows Hello can now be used to sign-in to the account. Probably won't use it in favor of an authenticator app.
Suppose I should do a test to see how passkey behaves for the account on a Windows laptop and how that will then work on a Chromebook...
Is there any key revocation or rotation mechanism for passkeys? Like if somehow my private key leaks, can I revoke it so it can’t be used to login? Or do I have to log into every site and revoke my old key and add a new one?
I always thought Passkeys is: Workflow for applications that aren't web applications. WebauthN only works in a browser, while passkeys work in "other" types of applications.
The fact that the private key is stored on iCloud is mostly irrelevant for understanding how it works, that's a client device implementation detail. There are software-only authenticators that work with WebauthN just fine and allow you to back them up.
webauthn can very much be used in a desktop application, you're just losing the phishing resistance factor, as the application can choose what to send as identifier, which includes collecting tokens for other tools/websites.
you can also use it natively in non-browser applications.
just the other day i've used it in a CLI application (which authenticated against web, but without real browser): https://github.com/Yubico/python-fido2
Is it the _goal_ of FIDO to get rid of passwords? If it is, I am against this industry group.
Passwords should always be kept as a valid authentication method.
The OP brings up a point about not having access to the private key... I agree with that. If I don't have access to the private key (like I currently do with ssh) then it's dead in the water to me.
> Passwords should always be kept as a valid authentication method
Why?
> If I don't have access to the private key (like I currently do with ssh) then it's dead in the water to me.
You don't have 'access' to the private key for any well designed HSM either. And there's nothing in the passkey spec that says you need to put the private key in at inaccessible place.
How losing a private key is different from losing a password?
Memorable passwords should be either an exception (like master passwords) or a device-specific thing.
And private keys do not have to be locked to a HSM. If this really matters, private keys can also be memorized if they were derived by a KDF, using a seed phrase.
They have to be, because they need to be synced across devices. The OS will try to protect these keys by putting them in a protected process, with all kinds of safeguards. But in the end, the private keys will still be available.
FIDO also supports device authenticators, where the private key (by design) never leaves the hardware. These devices can be used for the true 2FA.
The article said Apple/Google tries to become the guardians of private key. That isn't true according to my understanding. Private key can stay on private devices owned by the user and never leaves the devices.
1. With passkeys/WebAuthn you simply use private keys to authenticate. Almost exactly like with SSH keys, except that the keys are site-specific.
2. WebAuthn supports using hardware devices for 2FA, where the private key never leaves the authenticator device.
3. Passkeys are not like this. With passkeys, the private keys are managed by the OS and are synced across multiple devices. The OS has direct access to them, and so it's possible to extract these keys and do whatever you want with them.
Looks like the OP tried to simplify things, but I think he's takes it too far. No mention of how FIDO preserves privacy, or how WebAuthn works with the browser protect against phishing. It doesn't get much beyond saying it's a protocol based on a public / private key pair.
Perhaps that is fair enough because his problem seems to be on how that private / public key pair is managed, as evidenced by his comment at the end:"I am waiting for an open solution that will give me the authority to manage and sync passkeys". But if you make Joe Citizen responsible for the protection of the private key, you will end up with plain text copies of it everywhere. That doesn't look like a workable solution to me - it's barely better than passwords.
WebAuthn went to the other extreme - it seemed to built on assumption the private key was stored in a hardware token and could not be copied. But that meant your ID died when the token was lost or broke. In effect in WebAuthn the private key was so well protected it also wasn't a workable solution. (Actually, they had a published solution to the lost token problem - you kept multiple tokens, and authenticated with every site with all of them. I don't know why they though that was going to fly.)
Passkey is somewhere between those two extremes - companies with a track record in protecting private data keep a copy, and manage the transfer between secure repositories. It's a step down in security, because you how have to trust the company not to leak it. But to be fair, I'd trust Google's ability to keep it secure more than I'd trust myself. You also have to trust the company to not give copies to devices that could leak it. So far they only seem to be trusting phones they make, which is a big restriction but is understandable. I can live with those compromises.
I'm not so OK with "if Google deletes my account, I lose my key". They are talking of allowing the transfer of the private key to other companies. Google giving a copy Apple is an obvious example, as it would lets you transfer your ID from Android to iOS. But so far it's only talk. And if they continue to insist only a phone they control can be trusted to store the key then even if they do allow transfer it still leaves you with just two key minding providers - Apple and Google.
I don't know what to do about that. You can't trust any machine that lets the user have sudo access (or in general change the software) - so Windows and the traditional Linux desktop is out. (Obviously Linux itself and open source in general is fine - Android is Linux after all. The issue is Linux desktops give their users sudo and then by extension any malware that gets in the ability to change/access anything - including the private key.) Perhaps they might allow transfer to other dedicated tokens. A totally open source token that doesn't support firmware upgrades would work.
In any case the key management problem is complex. Damned complex. The "just make the user responsible for key management" throw away at the end of the OP is never going to fly. It's a simple solution to a complex problem - and it's wrong. The reason we are in this mess state now isn't because Google/Apple are trying to lock you in - it's because there are trying to provide something that works for most people, and there are no easy/fast easy solutions.
So is the idea there that that basically goes away with passkeys, and that your only "thing-you-know" protection is the x-digit passcode you punch into your phone?