The cryptography behind passkeys
blog.trailofbits.com
blog.trailofbits.com
Does anyone know the state of the standard wrt this? I know that they planned on doing something about it, just haven't kept up.
Unfortunately the spec authors think this export feature violates the spec and have threatened KeepassXC with being banned by authenticating websites[1]. This explicit support from the spec authors for client banning makes passkeys non-viable to me. The websites I log in to should not be able to restrict what clients I choose to use to manage my own data.
[1] Spec author writes, "To be very honest here, you risk having KeePassXC blocked by relying parties. ... (RPs [may] block you, something that I have previously rallied against but rethinking as of late because of these situations)." https://github.com/keepassxreboot/keepassxc/issues/10407
Basically, do what we say or expect us to have our corporate sponsors write bad press about your security.
They have no interest... in collecting subscription fees? I'm a satisfied 1Password customer, but it's hard to take this claim seriously. What does it mean? They literally get paid. Isn't that the definition of an interest?
> But how can websites know whether its users are using secure authenticators? Authenticators can cryptographically prove certain facts about their origins, like who manufactured it, by generating an attestation statement when the user creates a passkey; this statement is backed by a certificate chain signed by the manufacturer.
How many scummy companies trot out "Let me protect you from yourself" to justify taking away their users' freedoms?
One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation.
With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
For example, iOS uses the App Attest service (https://developer.apple.com/documentation/devicecheck/prepar...). On Android, you get it from Google Play Services (https://developer.android.com/google/play/integrity/overview) then the built in key attest service (https://developer.android.com/privacy-and-security/security-...). MS Authenticator does all the legwork and returns the results to you at sign-in time.
On Windows, WHFB has this built in (obviously). On macOS, this comes from Platform SSO (https://support.apple.com/en-ca/guide/deployment/dep7bbb0531...).
The spec failing to distinguish between these two cases is a major flaw and completely kills passkey viability for personal accounts until they resolve it.
I'm interested in reading more about this. Do you have some links? I did some quick searching of the terms you mentioned and nothing obvious came up.
Some quick bits and pieces from my own searching just now:
Apple's documentation on Passkey attestation is entirely under "declarative configuration", their terminology for mobile device management (MDM) corporate tools: https://support.apple.com/guide/deployment/passkey-attestati...
It is noticeably absent from, for instance, AuthenticationServices documentation: https://developer.apple.com/documentation/authenticationserv...
On non-attestation Passkey responses intentionally send an empty AAGUID for privacy/Apple's belief in the spec's suggestion to send an empty AAGUID:
> iCloud Keychain is one of the few (maybe the only?) passkey authenticator that currently follows the spec and will use an all-zero AAGUID.
From: https://developer.apple.com/forums/thread/739004
On the technical side of limitations of attestation for consumer Passkeys (due to iCloud Keychain sync):
> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.
> Attestation was designed to attest to a specific device, exclusively at the point of creation, with a specific set of security properties. It doesn't make sense for synced credentials for a number of reasons, including syncing to devices with different security properties, changes in security properties that happen after key creation, security properties of the sync fabric, sharing the passkey, or exporting to other passkey providers. We're working hard with W3C and FIDO to solve these problems.
From: https://developer.apple.com/forums/thread/708982
(I believe some of the problems being solved in that one in 2022 is referring to how we got the "uvi" and "uvm" extensions to Passkeys, neither of which is in attestation data nor attested in any way, and both designed for a general semblance of user privacy: https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension)
I believe the juiciest quotes I'm looking for are buried in WWDC videos and I can't find a transcript search tool just yet.
> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.
On any platform, attestation and "syncing" are effectively opposites. Either you're getting attestation that the auth comes from a secure application and on secure hardware (read: non-exportable in-TPM crypto material), or not.
As usual, it's a tug-of-war between security and convenience.
From a freedom perspective, I need to ensure that Google has no idea whether my device is an Android phone bought from an officially licensed manufacturer, or Waydroid or android-x86. Compliance is not an issue because I am, ya know, some random guy. The only way I can ensure this happens is by ensuring attestation is not possible.
The problem is that Passkeys really conflate two separate feature sets:
1. Synchronized password replacements. They _have_ to be represented as accessible clear-text to be synced between devices, at least during transit. So they can be stolen, for example, by malware that scans RAM for keys.
2. Keys that never leave a hardened hardware devices. Since they never leave the device, they can't be synced. But they're completely secure.
Effectively implementations already do that, and the spec could clear things up a lot by clearly defining one profile for synchronizing, non-attestation-capable, discoverable credentials called "passkeys", and another for hardware-backed, non-exportable, attestation-supporting ones called something else.
This technically is true because Passkeys are just a subset of WebAuth.
Apple doesn't support it at all anymore; Google only supports it for non-synchronized credentials (which are arguably not passkeys). Bitwarden obviously doesn't either (it can't, as a pure software implementation).
> One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
Developer of what? There's no competing software solution that supports attestation, and hardware authenticators complement software ones, rather than compete with them.
Not directly threatening but within that frame of mind:
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
The issue with hard tokens is that there is only one of them. By design, you can't back up a Yubikey's content to a second token. This means that any time you add 2FA to a new account, you must have all of your hard tokens in your possession to enroll them. This means a "one token on your keyring for daily use, one token in a safety deposit box as backup" approach isn't possible.
Yubico did propose a potential solution five years ago[0], but that proposal seems to have gone nowhere. Until something like that gets implemented, FIDO2 (and by extension Passkeys) requires some form software implementation backed by cloud synchronization to actually be usable for the average person.
[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
> When you need to signup for a new service on the go, you can add your backup key when you get to it
Requires you to remember doing that each and every time. Incidentally this isn't that different from just grabbing your keys like the parent suggested. Only it introduces a new variable: time delay. A lot can happen in that time and we all know the reality is that even a diligent person is going to slip now and then. It surely isn't a reasonable expectation for an average person.
every few months I swap 2 and 3, and re-enroll any missing (kept track of with a spreadsheet)
quite annoying, offline enrollment would be considerably better
It's absolutely a goal, since a PIN doesn't prevent your security key from loss, theft, or physical destruction.
What if you lose your device? Do you install alternate passkeys in a second device? Do you have to do that for every site and service?
That’s one way to look at it: passkeys are just a more convenient form of authentication compared to passwords. Although in my mind you’re arguably not achieving a whole lot considering the security bottle neck is still the same, being the login to your password manager.
I use physical Yubikeys so I’m a bit out of the loop here, but are there any methods for protecting your root password to your password manager in this scenario?
Many password managers do just that.
Effectively you have a secret that you are using to authenticate yourself. With pass keys managed by a vendor, you are trusting that vendor to manage your secret. If they are able to give your secret to someone else, then they can no longer confirm who all knows your secret.
I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone.
I'm also sure smarter people than me can surprise me with something, here. But secrets that can be shared historically tend to not be secrets for long.
the spec actually supports this, it's called caBLE
Asked differently, how does this get a vendor out of the picture?
But the FIDO alliance is apparently working on that: https://fidoalliance.org/fido-alliance-publishes-new-specifi...
I also have to confess this is clearly less convenient than having Apple or Google manage them for me.
If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).
Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.
For support matrices, see [1].
I back up my 12 word seed phrase, and then I can restore any and all my TOTP/FIDO/passkeys with another one if needed.
Searching online I found an answer on Stack Overflow stating that a PIN is required in this case: https://stackoverflow.com/a/79471904 How did you bypass it? I also find it idiotic that it is required. A PIN is just a password in another name, so we are back to using Yubikeys as the second factor in 2FA rather than a password replacement.
You need to buy a newer Yubikey with biometrics to make this work. I assume you have an older Yubikey and Google is getting to the standard by asking for a PIN.
I have a https://www.yubico.com/products/yubikey-bio-series/ and it works with Google exactly like you want it to, no PIN required. It's completely understandable to require a PIN if you don't have one of these though.
It’s no inconvenience though since the yubikey with a button to press and a yubikey with a biometric button to press work the same.
Is that how it works? A dropped house key essentially has a second factor (the address of the home), but if you have someones Yubikey that can be used for Google, is the Google Username stored in the Yubikey and accessible to the finder?
Like you can argue a dropped house key is similar to a dropped yubikey but i'd still give some benefit to the dropped house key involving real world attempts on locks with appropriate social suspicion on that if seen vs a dropped yubikey allowing anonymous attempts.
Eg. My Microsoft desktop, my Google phone, my Apple laptop all have passkeys setup individually that allow login to my various accounts such as my Google account.
So they aren't at all synced. They are all from different vendors but they can all login since i set them all up as passkeys. It's easy to do this too. Setup one site for passkey login via phone, go to that site on your desktop and select "auth via phone passkey" and use the phone passkey and then once logged in on the desktop go to account setup and select "Create a passkey on this device". The end result is you have multiple hardware security keys, namely your phone, desktop and laptop.
Hopefully better syncing comes soon but i'm ok with the current situation for now.
This is where the incentives push and is why we're unlikely to see usable or easy passkey sync.
I'm sort of ok with this (it will be a net security improvement) but it saddens me a little to see more of the web come under centralised control.
Most people won't fully understand the implications of this, which will be that the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.
Plus lots of secondary effects relating to fed auth providers having increasing leverage over the web in general.
You are conflating the old model of "log in with Google" and the new model of Google syncing your passkeys in an E2E way. The latter is more resistant to law enforcement misuse (not 100%, see All Writs Act in the San Bernardino shooter case).
It's a nuanced discussion because in practice today, email provider is regarded as ultimate source of truth regarding identity, except for high security domains e.g. where money is involved (banks, crypto) and it's economically viable for recovery to be high touch.
So having access to a user's email is the first "golden key".
Second is OIDC / social logins.
Third would be passkeys / stored passwords / an unlocked device.
My guess about the future is that OIDC / social login will prove to scale and grow better than direct passkeys in most instances. It's a better, more fully developed model for thinking about and managing identity lifecycle, passkeys themselves are a low level primitive by comparison.
Users will understand it (social login) better, providers will support it better (partly because corporates don't have any way to centrally manage passkeys at scale, nor should they) and finally because of the fallback / recovery problem for sites using passkeys.
Backup codes, sms phone recovery, alternate recovery email are all there in all of the above.
It's no different to forgetting your password/losing access to your password manager is it? As in i've literally at points lost access with passkeys (i only had 1 at the time) and the way i got back in was very straightforward and no different to losing access to a password manager. I got an email and typed my old password and i got back in and re-setup my passkeys.
The way I assess risk, that's less likely to happen than I am to lose my passkeys.
If I'm using passkeys but can recover my account with SMS, then why am I using passkeys? That sounds like the weak link of security. I'd rather use passwords, where I can understand what the password consists of rather than passkeys if I'm not getting an increase in security.
It's unfortunately not quite the same level of portability as passwords, as I don't think there's any standardized export/import format yet, but these options are significantly better than Apples's and Google's closed ecosystems.
> there is no syncing between keys
There is a similar problem even in OTPs. I switched phones not too long ago and some OTPs didn't properly transfer. I actually lost some accounts due to this, luckily nothing critical (I checked critical things but it's easy to let other things slip). The problem is that registering a new OTP removes the old ones. In some cases I've used recovery codes and in others the codes failed. IDK if I used the wrong order or what, but I copy-paste them into bitwarden, and I expect this is typical behavior.
99% of the time everything works perfectly fine. But that 1% is a HUGE disruption. With keys, I would even be okay if I had to plug my main key into a dock to sync them. Not as good as a safe, but better than nothing. I feel like we're trying to design software safes like we design physical safes. But if you lose your combo to a physical safe you always have destructive means to get in. With digital, we seem to forget how common locksmiths are. Googling, numbers seem kinda low but I'm not in a big city and there are at least 4 that I pass by through my typical weekly driving. So it seems that this issue is prolific enough we need to better account for actual human behavior.
[0] Don't get me wrong, I love them but I'm not willing to not undermine them via OTP creds because I need some other way in.
I feel like if I must choose between a 99% reliable syncing solution, and a non-existent automatic syncing solution that requires manual syncing, I would still choose the latter for its mental simplicity.
My point is that training doesn't seem to be effective to the general population. Frankly most people don't care. As we both probably know a big part is likely not knowing the importance
> The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user.
I agree. So get rid of needing to understand algorithms and simply require users to understand passkeys in relation to their house keys.
> This strategy has not been tried.
Have you tried to convince your friends to use messaging systems like Signal? What about PGP?
> understand passkeys in relation to their house keys.
There are plenty of cases where I know that people have misplaced Yubikeys. They might have a spare Yubikey. Or the equivalent to finding a locksmith is to log in with a non-passkey method. It's fine and in fact better if logging in without a passkey is considered an unusual fallback.
> A passkey synced using iCloud or Google account does not break that model
> Or the equivalent to finding a locksmith is to log in with a non-passkey method
Both of these were mentioned in my post you originally responded to: https://news.ycombinator.com/item?id=43988957
As I understand things, passkeys come in a few different varieties.
You can buy a yubikey if you want the credential tied to one specific physical device. Figure out your own backup strategy, such as spare yubikeys or printed recovery codes or whatever.
Or you can use apple/google/microsoft if you want your passkeys backed up to your cloud account. This means passkeys are basically the "Log In With Google" button, but with extra steps.
Actually it is a feature. The whole point of the Yubikey is that you can't extract the key. Syncing keys would mean extracting them, which would defeat the purpose of the Yubikey.
Now I am not saying that it is a feature you want. That's why there are other kinds of passkeys. My point is that it is not a flaw in Yubikeys, it is by design.
> Actually it is a feature.
The joke is quite old and part of what I'm pointing to. Security doesn't work well if it isn't very usable. At least this is a bit better than secure communication, but it isn't as huge of a difference as it might appear.
The biggest boon in security has come due to making these tools easy to use. That's from decades of experience is realizing you can't get everyone to be technical.
Passkeys use FIDO2, not PGP?
[1] https://fidoalliance.org/specifications-credential-exchange-...
https://github.com/fido-alliance/credential-exchange-feedbac...
I am worried about providers blocking exports “because security”. That’s Apple’s favorite argument
By a far and away WORTH the subscription, for me!
In effect, though, 1Password is both something you have (the device with 1P logged in, login requires a Security Key that you don't memorize) and something you know (the master password) or are (typically biometrics can be used to unlock for a period after entering the master password.)
Pretty much all the problems related to passwords are solved by passkeys, having them synced between your devices does not impact that.
Exporting/transporting keys seems to be optional on the part of implementors, but my solution has been to use Bitwarden, so I at least get cross platform keys.
Every vendor I see offering a solution has no documented export option at all. Yes, you can use the legacy method to login, but an authentication stream that is not used regularly is one that will break, or will ask for a factor that I no longer have access to (I wouldn't know this because I only use passkeys.)
I also expect that there will be sites that only accept passkeys eventually, even if the spec says you shoudln't.
But in general it's a bad idea to have the passkeys just sitting around in text files so the current managers are largely designed around preventing the tech support scammer from instructing grandma to dump the passkeys and email it to them.
Other than that, which is mostly only a benefit for edge cases around partially compromised devices or servers: yeah they're not much different than random unique passwords. Except they have vendor-lock-in.
But because most managers have no UI for doing this, it's impossible to trick someone into doing it.
I expect something akin to handing out the private key to your heirs is what happens. But the term "giving out" understates what happens: https://bitwarden.com/help/emergency-access/ It's an escrowed time lock. I haven't looked at the details, but I expect it's a multi step protocol involving at least two public keys. It the scheme of possibilities, it's pretty good.
If you die or become incapacitated, your emergency contact can click a button to request access to your vault. You receive a series of emails requesting that you approve or deny their request.
If you don't deny their request within a wait time that you specify in advance, your public key-encrypted user symmetric key is delivered to the the emergency contact for decryption with the their private key.
More here -> https://bitwarden.com/help/emergency-access/
I have heard this so many times that, given the big names behind the standard who benefit from vendor lock-in, it’s no wonder they are dragging their feet. Until there is a serious import/export mechanism, I’ll stay away.
I think that there are some objections about allowing user-friendly way to export passkeys as it's contradicts with their nature. But in the end they are exportable.
May be someone would build pure software implementation as browser extension which would allow export-import as PEM files and to hell with purists.
But yes, you can export passkeys. They take this format in the backed up JSON:
{
"passwordHistory": null,
"revisionDate": "2025-05-15T11:10:37.341Z",
"creationDate": "2025-05-15T11:10:37.134Z",
"deletedDate": null,
"id": "3b90b785-efb7-491b-92e8-525b446df781",
"organizationId": null,
"folderId": null,
"type": 1,
"reprompt": 0,
"name": "passkeys.io",
"notes": null,
"favorite": false,
"login": {
"fido2Credentials": [
{
"credentialId": "f167c754-5a4c-4c4a-b5e5-6faf18bde5a6",
"keyType": "public-key",
"keyAlgorithm": "ECDSA",
"keyCurve": "P-256",
"keyValue": "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgMnNsrXAHP50Glhs1vBPgCFVv3jj-nuZ9gHVRdGg2anehRANCAATtK7xFvDIn8mAOCniczaG5ytAE_eBR0kkgd5lFVahpI6tQ5U-nBAkgqvlmtObrWDNu0-RgiCgYnOLXFPEyda4j",
"rpId": "www.passkeys.io",
"userHandle": "47GTTn99QtyNUGaMFMzH2A",
"userName": "<masked against scrapers>",
"counter": "0",
"rpName": "passkeys.io",
"userDisplayName": "<masked against scrapers>",
"discoverable": "true",
"creationDate": "2025-05-15T11:10:37.645Z"
}
],
"uris": [
{
"match": null,
"uri": "https://www.passkeys.io/"
}
],
"username": "<masked against scrapers>",
"password": null,
"totp": null
},
"collectionIds": null
}
As for the lack of documented export options: that's kind of the point for many passkey providers. You can't export the key from a Yubikey, you can't export the keys from a smart card, you can't export the keys from an RFID dongle*, and in the same vein you cannot export the keys from many passkey providers.
What you can (or at least should be able to) do, is add a backup key. That can be someone else's PC/account in case your house burns down, or a physical Yubikey you store in a fire safe somewhere, whatever mitigations you need. You could also use a tiered setup; if you use hardware tokens to sign into your relatives' Apple/Google/Microsoft/1Password account, you can in turn use their cloud tokens to sign into whatever services they use. That way, you hand out some trust to their authentication provider, but in exchange managing physical backup keys becomes a lot easier as you don't need to open your safe every time you create a credential for an important website. You can use such a physical recovery key even if your relative prefers to log in with username+password.
On the flip-side, backup keys are not a solution for me in this instance. The model being proposed is one where we have hundreds of passkeys in our vaults, one for each service. I don't want to spend time setting up a backup key on every service; I want the ease of use of just hitting "use passkey" on a new site and having it all work. I just also want a 100% reliable backup option that has no dependency on any service, vendor-specific system or anything. Essentially, I want a backup that my grandmother could hand to a local kid with tech skills, and be able to get into my account(s) while sitting together at her computer.
This same pattern works for Google/iCloud accounts.
I've weighed the risks and decided that I'm more comfortable relying on Bitwarden for the most critical service than I am hosting in on my own hardware and counting on my own skills to keep it available. I self host plenty of other things, but having `rm -rf /`'d my hard drive before I don't trust myself more than I trust the folks at Bitwarden.
I can totally see the value for companies who serve users that don't use password managers—if you can get those people onto passkeys that's a clear security win.
I guess it will be a while before passkeys are the _only_ option that websites accept
Either one of us would have to choose to manually copy our logins into a phishing form in order to get phished.
Shameless plug: Here's one that is "something you know" :) https://github.com/lxgr/brainchain
It derives all keypairs from a passphrase, and rederives the private key from the key handle, similar to "stateless" hardware authenticators.
Please don't use it for anything important – it's a fundamentally bad idea, similar to "brain wallets"; I only implemented it to figure out whether it was possible, and to improve my own understanding of the WebAuthN and FIDO specifications.
If you then purchased passkeys that supported a custom seed, you could then replicate this seed to as many keys as you needed.
There are always security tradeoffs, but this was a mechanism to store something in the real world that had about 115 bits of entropy, as 'Something you know'
Most password managers and passkey implementations solve that problem by either requiring additional entropy (such as 1Password's "secret key") and/or rate limiting retrieval attempts using some zero knowledge based PAKE server-side (i.e. you can only retrieve the encrypted database if you can prove knowledge of the password, and attempts are rate limited).
My project does neither, so unless your passphrase is very high entropy, this approach is not secure. (And if it is high entropy – where are you storing that in turn?)
A password manager.
Neat project!
How well does password recovery work in those scenarios?
It's also not a good idea to store the backup at home – house fires are unfortunately a thing, and chances are you might not have time to grab either your main or your backup key.
You might argue "but if they still have the recovery methods isn't my account only as secure as those" and to that i'd point out that you're still way ahead with passkeys simply by not entering passwords on a routine basis. The recovery methods tend to be two factor as well, just without passkeys as one of the two factors (hence email+password) so still a win over password alone in any case.
Passkeys should be thought of as no different to the old two factor authenticators. I mean that's literally what they are, essentially the latest fido standard that allows devices such as your phone to be a hardware security key in its own right. These always had ways to do account recovery with all the providers.
Basically, when the system prompts to pick a key, click the "log in with phone" button, unlock your phone, and select the account/click "OK" to authenticate. The first time you do this, you need to scan a QR code to pair the phone to your computer, but after that you can use your phone whenever you need it.
Passkeys on Linux (and probably even more so on the more niche systems like the *BSDs) can use some love, especially when it comes to CTAP2. Chromebooks are probably the only Linux devices with native support for that.
If you want to safeguard against a fire, use a passkey provider that does exports (i.e. Bitwarden, KeepassXC) and then treat those exports the same as your password database file.
It seems like they're synced between devices using client-side encryption, with keys derived from your phone's lock code (typically only 4-6 digits). Is it possible that the passkeys are fully random, but then encrypted with far less than 128/256 bits of actual entropy while being synchronized between devices?
Could it be possible to brute force the keys server-side (IIUC, derived from 4-6 digit pins) with non-excessive amounts of compute? What am I missing?
As long as their vault is properly secured (with actual MFA) that shouldn't be too much of a risk, until they get hit with a virus, of course.
Generally, a one-time password is an additional security measure that prevents someone from going to a website and simply using obtained credentials (eg from a leak) or brute-forcing them. An attacker needs the second factor.
If you store your 2FA secret alongside your password in a password manager, you still gain protection from these attacks. And it's very convenient. However, you also increase your attack surface: if they break into your password manager, your done.
If your threat model allows it (mine does), this is still very secure and also very convenient.
I know many people who still reuse passwords, which certainly have been leaked, and are probably protected only by 2FA.
Or treat it as an opportunity to try to avoid "vendor lock-in"/increase redundancy by using all three to have 3+ passkeys in every service. Windows 11 can act as useful a bridge for bootstrapping all of your keys into a service: register for a site first on iOS or Android, use Windows 11 bluetooth to login via the first passkey, add a Windows passkey, and use Windows 11 bluetooth again to add the third. (Or some combo of that with the Windows iCloud Passwords app and/or Chrome.)
[1] https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
...Unless I misunderstood what you're talking about. When I put in a passkey, 1p just asks me to press a button, not re-unlock.
I feel that is too risky. Where would you store that passkey? And what if you lose it?
I suppose the 1p emergency kit could print out a QR code or something.
It's really more a convenience on a handheld device where entering a passphrase (mine is 20 characters) is a pain in the arse. Though, if it were available for macOS, I would use it there too.
Not implemented.
https://issues.chromium.org/issues/417941069 more here.
For my excuse I should note, that this passkey support is relatively recent (end of 2024) and error message was really unhelpful to understand the issue. I was trying to use passkeys on my Linux computer like every few months since they started to appear on various websites and was frustrated by lack of support in Linux.
Thanks for pushing me into right direction, so at least I can now use them.
Support is far from universal, but it's definitely getting better. Unfortunately, protocols such as CTAP2 don't seem to have been implemented on Linux, so it lacks the "log in using your phone" prompt that makes them super useful on proprietary operating systems (like fingerprint/touch ID, but without needing to add every device manually).
https://community.bitwarden.com/t/special-vault-search-keywo...
Maybe it's just a Bitwarden issue.
The 2FA issue isn't such for me. As I explained in a different comment, 2FA pins are copied automatically and are thus just a "ctrl+v" away.
Having to pull my phone out or go and find/fetch it to grab a pin is pretty annoying for me, since I also don't keep them in my password manager.
I did for a long time but figured that if my password manager was compromised I would be royally screwed since they'd have my 2FA there to, meaning the password manager is actually a weak point.
I remember this being an anti-MITM measure for u2f
Most large websites are hosted behind a CDN or a load balancer, which terminate the TLS session and is a MITM between the customer and the actual backend server. The problem is similar to TLS Client Certificate - you can't forward these to the backend now, and the load balancer is not smart enough to validate the data so it is impossible to use it.
In recent years (~5 years), AWS ALB and competitors gained the client certificate support now which pass the certificate information to your application in HTTP headers - instead of a standardized way of reading client certificate the servers has to read from non-standard headers.
If passkeys is also passed as HTTP payload, I don't see believe that the LB would read the payload anytime soon. It might become a selling feature for IDP-as-a-service like Auth0 that you can't do it with IaaS.
Passkeys just feel like a standard written by large tech companies as a flywheel technology to keep me locked into whatever hardware and software ecosystem I'm already in since seemingly no one besides maybe Bitwarden supports exporting them. Which seems pointless, because I don't know of any platform that supports importing them.
I am also getting tired of corporate white knight nerds defending trillion dollar companies telling me that portability isn't a concern.
FIDO/WebAuthn/Passkeys protect you against phishing, because of the origin binding mentioned in the article. On the phishing site, the required credential cannot be generated, and so no matter how convincing it is you can't accidentally give them a credential to forward.
Phishing is what these systems were trying to defend against.
Now if you were to say that the move from plain FIDO tied to a hardware key to passkeys tied to a Google account was a lock-in ploy ---- then I might be more inclined to agree.
To me this seems harder to pull off than a fraudulent password reset (either via social engineering, or a hacked email account). My TOTP fell in the drink a few years back, and some accounts very hard to reset and others were too easy.
It's not an acceptable trade-off. And the answer isn't, "Those third-parties shouldn't be asking for your password and TOTP," because that's not a realistic premise.
I suppose I might want to stop using 1Password someday, but it still has all my passwords as well so I can just fallback to those. And, honestly, only a fraction of the sites I have in 1Password have PassKeys available.
What I hate much more is sites that don’t have passwords and require you to log in via email every time. It drives me NUTS.
Compared to everything else, they are so much of a nicer experience. I despise the "click the link we just emailed you" so much. And MFA is a pain, and still has security issues: https://blog.talosintelligence.com/state-of-the-art-phishing...
I really don't get all the hate for Passkeys on HN...
It feels like the first step in a vendor lock-in strategy. Basically boils down to that. That's essentially my issue anyway.
This is crazy and should be outlawed. Honestly, it's so annoying...
You can’t copy a passkey to a different password manager, but you can create a new one for the same account, which is usually just as good.
> seemingly no one besides maybe Bitwarden supports exporting them. Which seems pointless, because I don't know of any platform that supports importing them
That may still change in the future :-). The thing is that the technology allows it, which is good, right?
Passkeys kind of take that concept, but make it suck. No backups. Terrible interoperability.
The other day I attempted to create one on my Mac with Firefox. The system passkey popup came up and made me scan a QR code with my iPhone that had to be connected to the internet. Bitwarden (my iOS passkey manager, that part works well) did open, but after selecting the profile to create the passkey in, it errored out. No passkey for me.
I've since disabled passkey support and we have no plans to attempt a new rollout anytime soon.
As far as I can tell the only people that have "successfully" rolled out passkeys are the companies with effectively zero user support and they just refuse to support passkeys at all, so if they don't work for a particular user: whatever.
TOTP is fully rolled out and well supported. Troubleshooting it is "hard", but at least it's possible.
TOTP troubleshooting basically boils down to 3 things:
* Server time
* User Phone/device time(most users opt to use their phone to generate TOTP, but we don't care)
* More than one TOTP saved for a given site(i.e. they didn't replace the old and created a new TOTP shared key) or not saved at all.
Our tech/user support helpdesk can handle this but it took a lot of training. We built special tools. We still get requests from them when they get overwhelmed with the complexity.
Passkey troubleshooting:
* Mobile network, including bluetooth
* Server network connectivity
* Computer/device network, including BT connectivity to mobile device.
Most tech support can't handle that much complexity at once. Shoot, most developers and tech "whiz" people can't either. The error messages one does get, if they are lucky, are very general and not helpful at all(last I checked).
Passkeys are not currently fit for production where you have to support the users. I hope they get there.
1Password is the only client/device implementation of Passkeys that pretty much just works. It saves the passkey in the 1p vault, and the 1p vault can be synced across devices.
It's something else that is unrelated to your password that you have to provide in order to log in, is that not the definition of a factor of authentication ?
Because it's phishable ?
Incidentally, passkeys go into my password manager too. You can probably work the math from there.
(I'm heterodox on this matter, though. I don't believe in the existence of "things you are" and "things you have". I think it's all ultimately just "things you know" and it's all better analyzed in terms of the cost of knowing and proving knowledge, and that the 3-factor framework for authentication is wrong.)
To address other security risks more comprehensively, you need to have a tight issuance process and use something key based in hardware. I’m working on a project where we deploy Yubi keys or similar, with an audit trial of which is used by who.
High trust environments need things like enterprise attestation and a solid issuance process to meet the control needs. Back in the day, the NIST standards required a chain of custody log of the token - you could only use in person delivery or registered mail to send them.
That’s overkill, but the point is the technology is only one part of the solution for these problems.
With TOTP (as well as passkeys) you as a consumer are safe from a vendor being hacked and your credentials being leaked from their side. You're also safe from fishing attacks.
On the other side using passkeys or password+TOTP a vendor is safe from credential stuffing of credentials a malicious actor gained through the above.
Sure you can say that it's both the same factor. But even so it has real security benefits which are much more important than just fitting in authentication factor categories that were thought up more than a decade ago.
There's a big difference for a malicious actor to gain access to millions of devices to steal the TOTP crypotgraphic string of users vs gaining access to a single vendor. TOTP doesn't save you from the first case but it sure as hell saves you from the second being disastrous.
The best you can do is attestation. Embed a certificate and private key in the TPM that says it's a real genuine FooBarCorp TPM, and sign all responses with that private key. This is terrible for the open ecosystem. It's also the only way to do the thing everyone sells their product on being able to do, so if it's allowed, then it's inevitable.
For fingerprints/etc you generally just need a great camera.
I hope Passkeys will become deployable, but the last few times we tried public key auth over web, it hasn't really work out all that well. However nobody but the DOD has been able to support it, and they only support it by brute force. It's not really deployable by anyone else. TLS client certs were never even tried seriously the UX was never remotely good enough. I fear Passkeys will be basically the same problem. UX is fine on the happy path, but the unhappy path is littered with broken at every turn.
I remember those QR codes and needing to use my phone when I tried passkeys a couple years ago when I was on an older Mac that didn't have hardware support for biometrics.
Every since I got a Mac with that support passkey creation has worked fine entirely on the Mac.
I don't want vendor lockin and I don't want proprietary third party cloud based backup/recovery.
Today with totp, I store the plaintext otpauth url and I can use oathtool to spit out codes when needed on my desktop. My phone has aegis, but I don't use any cloud based backup/recovery. I switched from Google Authenticator after they implemented their cloud based syncing to google.