I love passkeys. I love them being on my phone, requiring biometric authentication before unlocking. I just hate the vendor lock in that comes with it.
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.
I use Bitwarden to store my passkeys. Syncs to all my devices and just works. I have very few issues with it. Also for the truly paranoid, you can run the open-source back end on your own server if you want.
Can you export the passkeys to an importable form that your heirs can use to get into your accounts if you have passed away? Something that's sealed in an envelope inside a fire safe, for example?
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.
Generally, they should be able to get into any account with a death certificate, even if they don't know the password. It just takes longer. It took like 4 months for a friend to gain access to their dad's one-drive account to access photos on their computer.
This is not possible if the data on the server is encrypted with the key derived from the person's password or a completely independent key and no escrow has ever been implemented. That's why, for example, you can't read my old Wire messages or look at photos that I sent and received there, even if you fake my death certificate.
(I have deleted the account on passkeys.io so don't bother trying to hack my demo account)
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.
Thank you. This is helpful, as this is the first example of an actual key export that I've seen. The tiering system is interesting, that could work too.
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.
I didn't know Bitwarden exported passkeys. This makes me consider migrating from 1password to Bitwarden. I've been a happy customer of 1password for 8 years, but it doesn't export passkeys, so I've been quite reluctant to using passkeys because of how they would lock me into 1password.
It is my understanding that there is ongoing work to create an import/export standard, and that bitwarden is planning to support it. But also, you can give your heirs your bitwarden root password.
> It is my understanding that there is ongoing work to create an import/export standard
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.
Giving out the root password is less than ideal. I would prefer that my heirs not have to lie about their identity. I’m not singling out bitwarden here. Most SaaS offerings do not think about these issues. Pretty much every system should have a way of delegating authority without requiring lies.
Bitwarden paid users have a feature called "Emergency Access" where you designate one or more other Bitwarden users who can access your vault in an emergency.
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.
While I agree with the premise, to equate utilizing another’s credentials as lying conflates a system identity with a physical identity. Is it lying when I give someone the keys to my car to drive? And when will this ‘root’ character realize I’ve been appropriating their login with abandon?
> Giving out the root password is less than ideal.
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.
vaultwarden uses sqlite database, so obviously you can export it.
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.
Yes. If you use a password manager like 1password you can print out the recovery slip and write your password on it. Then all of your passkeys will be accessible.
I think you missed the point. If I have a passkey in 1password how does it become my passkey? As in, a passkey I can freely read, redistribute, and store in platforms that are not 1password. This is a property of passwords but not of passkeys.
Today you can do that with open source password managers, and in the future there is a passkey portability specification coming to do passkey migrations between managers.
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.
They're closer to a client side certificate - you never send the server your passkey, you sign data that proves you have it without exposing it. (Or something semantically equivalent anyway)
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.
Passkeys would be vulnerable to phishing if password managers allowed you to export them in plaintext. Because the phishing page would just show you the steps to do this and paste the private key in.
But because most managers have no UI for doing this, it's impossible to trick someone into doing it.
Password managers could warn about this, like "WEBSITES WILL NEVER ASK YOU FOR THIS DATA". I don't think we should cripple Passkeys and limit syncing to third-party walled gardens because users are stupid.
But how much more convenient is it really? Filling out the login form with Bitwarden is a single hotkey: Ctrl+Alt+L. That's such a light burden that I'm having a hard time seeing the value proposition for users who are already on a password manager.
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.
My passwords are bound to a domain and Bitwarden will refuse to autofill if the domain doesn't match. I can copy the password manually if I care to, but that's true in every passkey implementation that I've seen as well: they're never the only login option, you can always log in with a password too.
I don’t understand what you mean, sorry. If you are manually copying a password, then you are not using passkeys? There is nothing to copy/accidentally leak with passkeys.
I guess it will be a while before passkeys are the _only_ option that websites accept
I'm saying that as long as websites use the username/password model alongside passkeys with no way to turn off the former, you're just as at risk of phishing with passkeys as I am with domain-bound autofill.
Either one of us would have to choose to manually copy our logins into a phishing form in order to get phished.
It's not paranoid to host your own password manager. It's about not relying on Bitwarden for the most critical service without which I am locked out of pretty much everything. Plus, you get lots of cool features that are only available on bitwarden premium
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 register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey.
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.
This seems like a key failure point to me and why I've been a tad resistant[0]. If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.
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.
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.
There's a critical flaw in PGP actually. If you reply to any PGP encrypted email with "sorry, I couldn't decrypt" you'll, with high likelihood, get the cleartext version of the email soon after.
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.
> If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.
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.
I feel sorry for you, but I've also experienced bugs in password managers that fail to sync plain old passwords.
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 we need to address and solve these issues. I agree with you, but if we dismiss them then they don't get solved. The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user. Currently they are hard to maintain for technical users!
I don't think solving the syncing problem is as important as giving users clear expectations. The best way to teach passkeys to regular users is to use analogy. Consider the house key: the physical key that unlocks the front door of your house. You can have two keys on separate keychains so that you carry one of them and treat the other as a backup. But if your key is accidentally lost and potentially in the possession of a bad actor, you will want to change the lock on your front door. And if you do that, it is entirely your responsibility to change the keys on your other keychain.
We do do security by obscurity with our house keys; I don't label my house keys with my home address, while I do label my saved passwords with both the URL and my username. /shrug
I disagree. I think this strategy has been tried for awhile. Decades of security training has improved things but I don't think enough. Email encryption didn't resource get mass adoption until it was a seamless integration like in gmail or icloud. Same with text and phone, via Signal, WhatsApp, and iMessage.
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
This strategy has not been tried. Decades of security training has focused on credentials and objects that only exist inside a computer. And because it only exists in a computer, it is too abstract and not tactile enough for regular users to form a mental model. Yubikey is the one chance where we tie digital security to physical security and give people a clear mental model. Earlier you said that
> 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.
Have you tried to convince your friends to use messaging systems like Signal? What about PGP?
> understand passkeys in relation to their house keys.
Except they aren't the same thing. For exactly the reasons I was discussing. How often are locksmiths helping people get into their houses? What about their cars? It's a lot more common that you think.
You didn't get my point. It's not the lack of security training, but the issue is that the security training focuses on intangible things like passwords, domain names, links, emails. Yubikey is the opportunity to break this model and focus on tangible and tactile things that exist in the physical world. A passkey synced using iCloud or Google account does not break that model and will continue to be less understandable for real users than Yubikeys.
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
Yes, yes it does. Have you seen how hard it is to recover these accounts? There's not uncommon HN posts that do get these solved, but only then by high visibility. A method most people do not have available to them.
> Or the equivalent to finding a locksmith is to log in with a non-passkey method
Sure, it is just that the backup methods end up undermining the security key.
You can also simply register all your devices individually as a passkey and login with any one of them. Part of the point of the passkey standard was that you can simply have your laptop/phone/etc. act as a Fido2 backed security key in its own right. So if you have multiple devices it's pretty easy to set them all up as your passkeys.
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.
The NxM problem is at least better than the other problem where a website or app requires at most one passkey. WeChat (which is basically required if you need to talk to business associates or friends in mainland China) simply does not support multiple passkeys.
For myself it's really only the Google/Apple/MS accounts i'm using with passkeys so far (and third party sign in/chrome password syncing for the smaller sites) so N is small right now.
Hopefully better syncing comes soon but i'm ok with the current situation for now.
It seems like the obvious endgame is most people will use very strong auth between their devices and Google / Microsoft / Apple and then federate to everything else. All other workflows will become niche because it's not in monopoly interests to build features that make anything else convenient or manageable.
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.
> the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.
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).
Yep, I agree good outcomes are possible and an e2e sync'd passkey should have better privacy properties than a federated login.
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.
This scares me because I could get fully locked out if my house burns down or something. I like this property of a password manager. This seems to be in direct conflict with the design goals of passkeys.
Non-passkey based account access still works. As in i can go into my Google/Apple/MS account settings right now and in the security tab there's a ton of different options you can set.
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.
If I lose access to my password manager, I'd be substantially boned. But I'm less worried about that. It would require me to forget my password, or 1password to get pwned, go bad, or lose data.
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.
Account recovery with the big providers that support passkeys is two factor from what i've experienced, eg. sms+email, email+old password or sms+recovery code etc. so definitely a step up from password login.
Many password managers these days support passkeys and can synchronize them in whatever way you use to also sync your passwords (i.e. a cloud backend, but also a self-hosted Syncthing shared folder etc.)
I can easily export and import my passwords from my password managers and do whatever I want with them. I enjoy having that lever over my subscription.
There are several subscription-free password managers available that support passkeys, e.g. Bitwarden (self-hosted), Strongbox (lifetime version available), or KeepassXC.
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.
I tried setting this up for a non-technical friend who was gifted multiple brand new Yubikeys. The goal is to log in to Google using any one of the Yubikeys with no password. Unfortunately doing so causes Chrome to pop up a dialog requesting a PIN for the Yubikey. How did you solve that problem?
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.
Passkeys need to have two factor to count as a passkey per the standard. Otherwise in theory someone could steal your key alone and get in (a big risk).
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.
I don't understand why someone stealing my key and getting in is a big risk. They could steal my house key and get into to my house and do far greater damage: grab all physical documents and grab all computers where their full disk encryption key is in RAM.
Finding a dropped yubikey and immediately having access to someone’s google account is simply reasonably a bridge too far if that ever became commonplace. Someone decided not to allow that footgun to the public.
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.
> Finding a dropped yubikey and immediately having access to someone’s google account
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?
You should at least need the username but i still totally get the bar being set where it is.
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.
I always ask how you expect to defeat the vendor lock in?
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.
> 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.
the spec actually supports this, it's called caBLE
Right, that flow seems somewhat straight forward and is roughly what I had in mind with my sentence. It doesn't really break you out of vendor involvement, though? You both still have to be fully in on the whole flow. Right?
Asked differently, how does this get a vendor out of the picture?
I actually thought it was more for mediating confirmation of access to them. You don't share the secret with the new party, but you and the vendor both do a flow with them to confirm that someone claiming to be an identity can support that claim.
Do not use a vendor for managing passkeys. Use a self hosted password manager like vaultwarden. Or spin up an OIDC provider with pocket-id. Using a vendor is just pointless and should be avoided at all costs
The FIDO Alliance (who wrote the WebAuthn spec with the W3C) has a draft specification for a format (Credential Exchange Format) and protocol (Credential Exchange Protocol) for migrating passkeys and other credentials [1]. I don't think this is implemented by any providers yet, but it's being worked on.
On Android, Keepass2Android developer is working on supporting passkeys in the near future (https://github.com/PhilippC/keepass2android/issues/2099) but I'll be honest, I haven't dedicated enough time learning about passkeys to be sure the app will be able to support all implementations of passkeys and avoid vendor locking completely.
For me, the only thing that makes passkeys viable is backing them up in the cloud and automatically syncing them across devices. Otherwise, I do not trust them.
Not the parent, but the obvious answer is: a hard token (e.g. Yubikey). After all passkeys are just a software emulation of the smart card / FIDO2 mechanism that's been around for many years.
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.
It works well enough. When you need to signup for a new service on the go, you can add your backup key when you get to it. Having the backup key in a safety deposit box hardly accessible seems like a non-goal given you protect it with a pin with a very limited number of retries.
> When you need to signup for a new service on the go, you can add your backup key when you get to it
Good on paper, bad in practice.
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.
I'm not sure if this is satire. You trust the "cloud" and whatever does the syncing to the cloud? I definitely don't trust anything that "syncs to the cloud".
I read their comment to be “I trust myself to lose a hardware key, but not a software key that’s backed up and synced across all my devices.”
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?
If it is encrypted (incl. the filenames), sure, but is it usually the case? If I do it manually, of course it would be, but all these modern "sync to cloud" solutions, I absolutely do not trust.
Sure, why not? The cloud is just somebody else's computer, and if I don't trust that somebody to not take a peek, I'll make sure to encrypt my data first.
Passkeys are highly phishing resistant in a way that passwords are not and are not subject to credential reuse (though password managers somewhat solve the first problem and almost entirely solve the latter problem.)
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.)
No. The service you are logging in to does not hold the keys so they can't be leaked, passkeys do not get reused between services, it's effectively impossible to fall for phishing attacks with passkeys, and it's effectively impossible to fall for scammers trying to get your keys since there isn't any mechanism to directly dump the private keys out.
Pretty much all the problems related to passwords are solved by passkeys, having them synced between your devices does not impact that.
A passkey is a public-private keypair strongly tied to a specific site. Sites never have access to the private key, and the key will never be presented for use on the wrong site. Those two advantages remain even if the passkey is stored in software or synced over the cloud.
That's my impression as well, and the nature of computing today /encourages/ putting passkeys into some container that means that they can be accessed from other pieces of hardware at different locations.
From a practical perspective, passkeys are mostly identical to passwords where (1) secret generation is guaranteed to be strong, random, and unique; (2) they're tied to a specific site, so they can't be phished; and (3) filling is standardized and therefore ergonomic. If your passwords have those properties, passkeys aren't really an improvement for you. The main benefit to savvy consumers is that websites can trust that your passkeys are actually high quality and treat them as a primary authentication mechanism, instead of only a weak factor in an MFA system. And of course the huge huge benefit to most (unsavvy) consumers is that, you know, they're actually secure/unique and phishing-resistant.
Normal passwords can be phished, no matter how strong it is. The weak link is always a careless human. Passkeys are definitely a huge improvement for everyone, apart from the vendor-lock in which can be avoided
You can get around it, of course, but password managers are aware of the correct domain for a password and will only auto fill it into a form on the right domain. This is phishing-resistant. I'm not saying it's perfect, and I'm a big passkeys advocate. But "randomly generated password auto-filled by 1password" already meets many of the same benefits as passkeys, kinda, so long as auto-fill works on that particular website. Passkeys, in addition to stronger versions of those properties, also provide (1) ergonomics/standardization ("fill" works everywhere) and (2) sites can trust them to be strong.
Imagine using the worst password manager out there. 1Password was breached several times and even led to some people losing significant amount of money
Can you expand on the vendor lock aspect? I have stored passkeys in my password manager, so they feel pretty portable to me. Is it that each service requires a unique passkey? That seems comparable to how each service would require its own TOTP seed.
KeepassXC lets you export the private key, which you can then back up or import into another KeepassXC instance. I have tested this, it works. I even shipped my exported private key off to a friend in another state and he was able to import it into a KeepassXC instance and log in to my account. Presumably another password manager could support importing the data, as it's just plaintext, though I don't know if any do.
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
Furthermore, they "heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers."
Basically, do what we say or expect us to have our corporate sponsors write bad press about your security.
Just having the data exported is peace of mind for me. It's trivial to import or convert to another format (even if not implemented now), so the worst-case scenario is acceptable, especially considering how much better Bitwarden + Passkeys are to every other form of authentication.
> we have no interest in creating a walled garden or locking you into 1Password.
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?
> Does anyone know the state of the standard wrt this?
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.
Unfortunately I don’t think there’s much to help with vendor lock in directly (like, you may or may not be able to export the private key(s) depending on the tool, and in some cases it’s definitely not possible like with a hardware key), but any website that supports passkeys supports WebAuthn in general so you shouldn’t have difficulty migrating to another tool if desired, although you would need to register again.
Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. Lock-in is built into the design.
One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
Attestation is probably the best feature of passkeys.
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.
This is fine for corporate settings, where the data is not owned by the user but by the company. But it's completely unacceptable for managing one's own personal account. What do I do if I do not trust proprietary software to manage my ability to log in to online services? How can this be compatible with open source passkey providers?
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.
Apple has stated very publicly and in multiple places/ways that Consumer Passkeys will never include attestation data on Apple hardware. That's not "the spec", but it is still currently a big enough moat to protect Consumer usage of passkeys away from Corporate needs, given most Consumer apps/websites probably want iOS/iPadOS/macOS (in decreasing interest) users today.
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.
(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.
Attestation is only about security if there are ways for people to handle it themselves. Think of them like certs where anyone can buy one or get one for free using lets-encrypt. I should be able to attest my own keys in a similar way. If I cannot then they are not really about security but about control and lock-in.
Attestation is probably the worst feature of passkeys.
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.
> Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service.
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.
This is largely a problem because the specification does not cleanly call these out as two completely different feature sets, e.g. via "profiles" or a similar mechanism.
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.
None of the common passkey implementations support attestation.
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.
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'
The problem is that most humans aren't capable of remembering high-entropy passwords, and are even worse entropy sources.
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?)
This is a really common question but it has a really simple answer. They still have recovery methods. You can optionally change these with most providers (go into account settings, setup something like a recovery codes and check the option to be completely passwordless) but regardless they still have recovery methods. As in i lost my phone and i recovered the account with a combination of my secondary email and old password.
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.
Using CTAP2, you can authenticate a passkey on any Windows laptop. macOS also has decent support (though not as seamless if you're not using an iPhone because of course it isn't). I personally do it when I need to boot Windows for something, using the Bitwarden app to expose passkey logins to my laptop.
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.
You can use the same passkey for multiple devices (for example with keepassxc as authenticator that handles them), but it reduces security same as for example with using ssh private key that's not unique per device.
You should be able to revoke needed passkeys then. I.e. let's say you lost device A. May be revoke access for associated passkey for all places where you used it, but the rest of them would remain OK. Not sure how sites handle that (if at all).
And you need to register for every new service you create an account with.
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.
Somewhat off-topic: Does anyone know the underlying strength of the keys used as the "root of trust" behind passkey synchronization on Android/iOS? I can't find a lot of documentation on this.
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?
A confidential channel can be established over an insecure medium using e.g. Diffie-Hellman key exchange.
To protect against MITM, an out-of-band QR/bluetooth can be used.
Typically you see symmetric encryption keys (AES-256 is the most common), derived from a Password KDF. I don't know what Google or Apple do specifically, but that'd be my first guess.
I see everyone putting their TOTP and second factor in the same vault as their username/password. Doesn't this defeat the purpose of the second factor to some degree?
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.
Yes it’s then two step verification not two factor, a bit less secure but a lot more convenient (age old trade off between the two). The benefit you get compared to having only password is that it’s now time based instead of static.
It's about accountability sinks. The purpose of requiring the second factor is for the company to blame the user when the user gets hacked. It has very little to do with actual security.
With TOTP you have a private key that you don't transmit over the wire, as opposed to your password, so security is improved even though the password and TOTP is in the same vault.
Agreed Stefan! I keep mine in separate vaults for this purpose. I’m still not on board with passkeys yet, but the discussion here makes BitWarden seem like the best solution.
At the moment, I'm going to avoid them as long as I can. It's not that I don't like the concept, but I think that a strong password + 2FA is already "enough" and I don't need to add complexity to my setup. No, I don't really fear phishing.
By "complexity" I meant that they are "opaque" to me and somewhat not tied to and identity (be it email or username). Maybe it's me being inept, but I used them once or twice just for fun in Bitwarden and now I can't find them anywhere in my vault.
I've got no overall stats but they are very well integrated in to iOS. You could end up using them without really even knowing what passkeys are. Websites and apps just prompt you with "add a passkey" and if you hit accept you get one and it gets synced to all your other Apple devices and just works.
1Password and BitWarden both support Passkey sync across all three OSes. Though if you are using Android regularly enough that may imply you trust Google implicitly enough that you probably could also just get away with Chrome Passkey sync which I'm told also works on all three OSes today.
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.)
KeepassXC is a good client that lets you handle your data how you want. I wrote a pro-Passkey blog post here[1] that explains how to do your own syncing, though I later discovered Passkeys are explicitly built to support proprietary software vendor lock in and had to revoke my support. If you are concerned about being able to control your own data outside of the big tech ecosystem, I strongly recommend avoiding passkeys entirely. It is possible for now, but they are not built for that and the spec authors are actively hostile to you managing your own data.
That is what I've noticed as well. The thread regarding KeePassXC is crazy... straight up threatening negative PR because KeePassXC allows people to store their private key, demanding that they instead take away user choice and modify their app to hide & prevent users from doing things. Passkeys appear to me to be nothing more than a corporate gimmick, and to be honest, I personally think in many instances they actually make you less secure... getting a fingerprint is way easier than making someone tell you their password. Now days the intelligence agencies likely already have your fingerprints as well.
I also meant to mention that many Keepass clients support Passkeys already today. Strongbox on iOS and macOS has similar or better integration to 1Password/BitWarden. Windows you probably want KeepassXC for now as it isn't fully baked in mainline Keepass. I don't know what you'd use on Android today, but I'm sure there's at least one and probably more on the way.
Bitwarden is free, and if you are concerned about these terms changing, the excellent self-hosted open source server implementation "vaultwarden" [1] supports passkeys as well.
I've used them across Chrome, Firefox, and Safari on Linux, macOS, and Windows (10 and 11) for large websites. I've used them for Github, as 2FA on various services, and as the primary login for some websites, such as the local grocery store (Albert Heijn). I also use them for authenticating to my personal Keycloak server which acts as a guard for a whole bunch of services in my network.
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).
Google documentation states in multiple places that passkeys are supported in chrome Linux via google password manager. I haven't tried myself, are you saying that is incorrect?
Yes/no. I have a few passkeys in my vault but several are for different accounts with the same company (e.g. Amazon, Google). I expect adoption to continue but will take years.
I hope 1Password release passkey unlock for vaults soon. Then I'll never have to enter the passphrase to unlock again, and my "passphrase" will be essentially the unlock code for my phone.
You can already unlock 1Password using biometrics in your Apple devices. they do ask you for your password every 2 weeks though. But I think that's a great balance.
...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.
With a passkey you would have one in keychain that unlocks 1p. So you will only be asked for your phone password/unlock code whenever iOS asks, but it will be used to unlock 1P. Never need to enter your 1P passphrase.
The passkey is stored in the secure enclave which is protected by your unlock code & biometrics (for fast unlock), or whatever the equivalent is for Google. You're not replacing your secret key / passphrase, it's just a different way to authenticate and decrypt vaults.
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.
Because the browser knows the internet domain that the login/registration is for. And the browser also provides the JavaScript API to talk to the authenticator (navigator.credentials.create and navigator.credentials.get).
My friend asked similar question yesterday, and while I don't know the answer I wish it don't
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.
Passwords and password managers seem good enough to me, and TOTP support is everywhere now.
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.
Password/TOTP does not protect you against phishing. The phishing site can forward the password and TOTP you type into the real system, gaining your access.
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.
Considering there's an entire portion of the software industry built on accepting a user's credentials and also prompting them for their TOTP, I don't think this really matters.
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.
> The phishing site can forward the password and TOTP you type into the real system, gaining your access.
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.
If you're targeting a particular person, social engineering is probably easier. If you just want to illicitly harvest some accounts, and aren't too worried about which ones, blasting out emails linking to hacked websites that fake the login & TOTP flow is very easy.
A couple years ago there were several posts here about not using PassKeys, and I went along with that for a bit. But I’ve fallen in love with them. They’re so nice to use with 1Password.
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.
Passkeys are honestly the most frictionless system. No more waiting for 2FA codes and having to type them in. No more getting locked out of your accounts if you lose your phone.
Passkeys are an API that requires the use of a password manager. It doesn’t lock you into any hardware any more than your password manager does already.
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.
I use Yubikeys as my passkeys, and in terms of security it's strictly superior to passwords.
> 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?
Challenge-response with asymmetric encryption is pretty much perfect. I wish all auth worked like SSH.
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 implemented passkeys @ $WORK, and we rolled it out to our tech department only first. Nobody could make it work reliably, and troubleshooting it was basically impossible. The best you could do was just wipe their passkeys and have them try again.
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.
Regardless, TOTP is way better than passwords alone, or SMS as another factor. It's also the only one that can be deployed at scale that is supportable.
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.
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 ?
Passwords are "something you know". TOTP is "something you know". It wanted to be "something you have", but it's not. Proof: I can put TOTP tokens into my password manager now. Anything that can go into my password manager is proved to be "something I know" by the fact I can put it into my password manager.
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.)
Yes. Passkeys help with the bad password problem. That’s a big deal but doesn’t magically solve everything.
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.
Within the larger spec, you can whitelist a set of known devices, such as only allow Yubikey's, etc. Which would prevent the private key material from getting into your password manager.
You can but the server can require an device attestation during registration, proving that you're actually using an Yubikey or whatever. That isn't possible with TOTP
Incidentally, biometric scans can also go in password managers. Turns out it's all just bits. Who knew?
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.
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.
I haven't had any problems with syncing and using passkeys with 1Password and Firefox on MacOS, iOS, or Windows. When the site wants to create or use a passkey I get a prompt from 1Password on the device that I'm using. No need to involve a second device (which for me I'm fine with security-wise. If I really wanted to be sure there was no way of malware extracting the keys I would be using my Yubikeys)
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.
FWIW, I migrated to ed25519-sk SSH keys backed by FIDO2 credentials on my Yubikeys, and I really love it. The fact that my credentials effectively can never be lifted out of my hardware key is quite comforting.
Is there a "platform authenticator" that allows import/export of the actual origin site, keypair, and credential id in plaintext? The next would be a variety of platform authenticators able to import and use those?
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.
KeepassXC allows this, but the spec authors think this is bad and have threatened KeepassXC with being banned by authenticating websites. The spec has explicit support for banning clients built in. https://github.com/keepassxreboot/keepassxc/issues/10407
Some open source password managers provide this, but the general industry is working on a way to transfer between hosts without having to dump everything out in plain text in between.
Passkeys live at the OS level not the app level. If they have a passkey that allows access to their Google account the passkey will still be there if they uninstall Youtube.
I believe the complaint here is that the YouTube app on iOS is an Authenticator for Google Accounts today. I didn't know it was doing anything Passkey-specific on iOS, but that wouldn't shock me given all the other ways it currently is the de facto Authenticator app for your Google Account on iOS today.
I love passkeys. I love them being on my phone, requiring biometric authentication before unlocking. I just hate the vendor lock in that comes with it.
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.
I use Bitwarden to store my passkeys. Syncs to all my devices and just works. I have very few issues with it. Also for the truly paranoid, you can run the open-source back end on your own server if you want.
https://bitwarden.com/passwordless-passkeys/
Can you export the passkeys to an importable form that your heirs can use to get into your accounts if you have passed away? Something that's sealed in an envelope inside a fire safe, for example?
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.
Generally, they should be able to get into any account with a death certificate, even if they don't know the password. It just takes longer. It took like 4 months for a friend to gain access to their dad's one-drive account to access photos on their computer.
This is not possible if the data on the server is encrypted with the key derived from the person's password or a completely independent key and no escrow has ever been implemented. That's why, for example, you can't read my old Wire messages or look at photos that I sent and received there, even if you fake my death certificate.
Legacy contacts are the pattern here.
https://support.apple.com/en-us/102631
No chance that's happening with Google.
https://support.google.com/accounts/troubleshooter/6357590?h...
Good luck not getting burnt by Google's classic lack of support... https://www.reddit.com/r/google/comments/1fclx16/google_dece...
Bitwarden's hosted platform has a feature exactly for this use case: https://bitwarden.com/help/emergency-access/
But yes, you can export passkeys. They take this format in the backed up JSON:
(I have deleted the account on passkeys.io so don't bother trying to hack my demo account)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.
Thank you. This is helpful, as this is the first example of an actual key export that I've seen. The tiering system is interesting, that could work too.
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.
I put the passkeys in a password manager, then lock the password manager with multiple physical Yubikeys, keeping several in secure storage.
This same pattern works for Google/iCloud accounts.
I didn't know Bitwarden exported passkeys. This makes me consider migrating from 1password to Bitwarden. I've been a happy customer of 1password for 8 years, but it doesn't export passkeys, so I've been quite reluctant to using passkeys because of how they would lock me into 1password.
I switched last month and it is basically the exact same flow except.. you don't have to pay due to self hosting.
It is my understanding that there is ongoing work to create an import/export standard, and that bitwarden is planning to support it. But also, you can give your heirs your bitwarden root password.
> It is my understanding that there is ongoing work to create an import/export standard
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.
Giving out the root password is less than ideal. I would prefer that my heirs not have to lie about their identity. I’m not singling out bitwarden here. Most SaaS offerings do not think about these issues. Pretty much every system should have a way of delegating authority without requiring lies.
Bitwarden paid users have a feature called "Emergency Access" where you designate one or more other Bitwarden users who can access your vault in an emergency.
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/
While I agree with the premise, to equate utilizing another’s credentials as lying conflates a system identity with a physical identity. Is it lying when I give someone the keys to my car to drive? And when will this ‘root’ character realize I’ve been appropriating their login with abandon?
> Giving out the root password is less than ideal.
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.
vaultwarden uses sqlite database, so obviously you can export it.
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.
Yes. If you use a password manager like 1password you can print out the recovery slip and write your password on it. Then all of your passkeys will be accessible.
I think you missed the point. If I have a passkey in 1password how does it become my passkey? As in, a passkey I can freely read, redistribute, and store in platforms that are not 1password. This is a property of passwords but not of passkeys.
Today you can do that with open source password managers, and in the future there is a passkey portability specification coming to do passkey migrations between managers.
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.
if a passkey is exportable how is it materially different from a password? Isn't the point of a passkey to be hardware bound so it can't be swiped?
They're closer to a client side certificate - you never send the server your passkey, you sign data that proves you have it without exposing it. (Or something semantically equivalent anyway)
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.
Passkeys aren't vulnerable to phishing or breaches (if they are you have bigger problems).
Passkeys would be vulnerable to phishing if password managers allowed you to export them in plaintext. Because the phishing page would just show you the steps to do this and paste the private key in.
But because most managers have no UI for doing this, it's impossible to trick someone into doing it.
Password managers could warn about this, like "WEBSITES WILL NEVER ASK YOU FOR THIS DATA". I don't think we should cripple Passkeys and limit syncing to third-party walled gardens because users are stupid.
What do passkeys synced over Bitwarden get you that a username + random password does not?
Same thing SSH keys give you what username + random password does not. Convenience.
But how much more convenient is it really? Filling out the login form with Bitwarden is a single hotkey: Ctrl+Alt+L. That's such a light burden that I'm having a hard time seeing the value proposition for users who are already on a password manager.
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.
Phishing protection? Unlike passwords, passkeys are bound to a domain.
My passwords are bound to a domain and Bitwarden will refuse to autofill if the domain doesn't match. I can copy the password manually if I care to, but that's true in every passkey implementation that I've seen as well: they're never the only login option, you can always log in with a password too.
I don’t understand what you mean, sorry. If you are manually copying a password, then you are not using passkeys? There is nothing to copy/accidentally leak with passkeys.
I guess it will be a while before passkeys are the _only_ option that websites accept
I'm saying that as long as websites use the username/password model alongside passkeys with no way to turn off the former, you're just as at risk of phishing with passkeys as I am with domain-bound autofill.
Either one of us would have to choose to manually copy our logins into a phishing form in order to get phished.
It's not paranoid to host your own password manager. It's about not relying on Bitwarden for the most critical service without which I am locked out of pretty much everything. Plus, you get lots of cool features that are only available on bitwarden premium
The mission critical problem cuts both ways.
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 register my Yubikeys on account.google.com (and around the web, e.g., fastmail.com) as passkeys. If you visit the account security page[0] and enable "skip password when possible", then you can log in to Google with only a Yubikey-backed passkey.
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].
[0]: https://myaccount.google.com/security
[1]: https://passkeys.dev/device-support/
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.
> This seems like a key failure point
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.
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.
> There's a critical flaw in PGP actually.
Passkeys use FIDO2, not PGP?
> If there isn't some form of automatic backup then I guarantee I will not have a sync when I need it the most.
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.
I feel sorry for you, but I've also experienced bugs in password managers that fail to sync plain old passwords.
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 we need to address and solve these issues. I agree with you, but if we dismiss them then they don't get solved. The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user. Currently they are hard to maintain for technical users!
I don't think solving the syncing problem is as important as giving users clear expectations. The best way to teach passkeys to regular users is to use analogy. Consider the house key: the physical key that unlocks the front door of your house. You can have two keys on separate keychains so that you carry one of them and treat the other as a backup. But if your key is accidentally lost and potentially in the possession of a bad actor, you will want to change the lock on your front door. And if you do that, it is entirely your responsibility to change the keys on your other keychain.
We do do security by obscurity with our house keys; I don't label my house keys with my home address, while I do label my saved passwords with both the URL and my username. /shrug
I disagree. I think this strategy has been tried for awhile. Decades of security training has improved things but I don't think enough. Email encryption didn't resource get mass adoption until it was a seamless integration like in gmail or icloud. Same with text and phone, via Signal, WhatsApp, and iMessage.
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
This strategy has not been tried. Decades of security training has focused on credentials and objects that only exist inside a computer. And because it only exists in a computer, it is too abstract and not tactile enough for regular users to form a mental model. Yubikey is the one chance where we tie digital security to physical security and give people a clear mental model. Earlier you said that
> 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.
Have you tried to convince your friends to use messaging systems like Signal? What about PGP?
Except they aren't the same thing. For exactly the reasons I was discussing. How often are locksmiths helping people get into their houses? What about their cars? It's a lot more common that you think.You didn't get my point. It's not the lack of security training, but the issue is that the security training focuses on intangible things like passwords, domain names, links, emails. Yubikey is the opportunity to break this model and focus on tangible and tactile things that exist in the physical world. A passkey synced using iCloud or Google account does not break that model and will continue to be less understandable for real users than Yubikeys.
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.
You're not getting my point though.
Yes, yes it does. Have you seen how hard it is to recover these accounts? There's not uncommon HN posts that do get these solved, but only then by high visibility. A method most people do not have available to them. Sure, it is just that the backup methods end up undermining the security key.Both of these were mentioned in my post you originally responded to: https://news.ycombinator.com/item?id=43988957
You can also simply register all your devices individually as a passkey and login with any one of them. Part of the point of the passkey standard was that you can simply have your laptop/phone/etc. act as a Fido2 backed security key in its own right. So if you have multiple devices it's pretty easy to set them all up as your passkeys.
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.
My issue with this is the NxM problem, if you want to do this on 10 websites with 5 devices you need to maintain 50 passkeys.
The NxM problem is at least better than the other problem where a website or app requires at most one passkey. WeChat (which is basically required if you need to talk to business associates or friends in mainland China) simply does not support multiple passkeys.
I find it odd to be designing our technology based around ease of use by totalitarian governments.
For myself it's really only the Google/Apple/MS accounts i'm using with passkeys so far (and third party sign in/chrome password syncing for the smaller sites) so N is small right now.
Hopefully better syncing comes soon but i'm ok with the current situation for now.
It seems like the obvious endgame is most people will use very strong auth between their devices and Google / Microsoft / Apple and then federate to everything else. All other workflows will become niche because it's not in monopoly interests to build features that make anything else convenient or manageable.
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.
> the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.
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).
Yep, I agree good outcomes are possible and an e2e sync'd passkey should have better privacy properties than a federated login.
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.
This scares me because I could get fully locked out if my house burns down or something. I like this property of a password manager. This seems to be in direct conflict with the design goals of passkeys.
Non-passkey based account access still works. As in i can go into my Google/Apple/MS account settings right now and in the security tab there's a ton of different options you can set.
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.
If I lose access to my password manager, I'd be substantially boned. But I'm less worried about that. It would require me to forget my password, or 1password to get pwned, go bad, or lose data.
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.
Account recovery with the big providers that support passkeys is two factor from what i've experienced, eg. sms+email, email+old password or sms+recovery code etc. so definitely a step up from password login.
I've been using keypassxc which supports passkeys. It works for github at least
Many password managers these days support passkeys and can synchronize them in whatever way you use to also sync your passwords (i.e. a cloud backend, but also a self-hosted Syncthing shared folder etc.)
I can easily export and import my passwords from my password managers and do whatever I want with them. I enjoy having that lever over my subscription.
There are several subscription-free password managers available that support passkeys, e.g. Bitwarden (self-hosted), Strongbox (lifetime version available), or KeepassXC.
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.
I just use a Trezor One (yes, a bitcoin hardware wallet).
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.
I tried setting this up for a non-technical friend who was gifted multiple brand new Yubikeys. The goal is to log in to Google using any one of the Yubikeys with no password. Unfortunately doing so causes Chrome to pop up a dialog requesting a PIN for the Yubikey. How did you solve that problem?
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.
Passkeys need to have two factor to count as a passkey per the standard. Otherwise in theory someone could steal your key alone and get in (a big risk).
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.
I don't understand why someone stealing my key and getting in is a big risk. They could steal my house key and get into to my house and do far greater damage: grab all physical documents and grab all computers where their full disk encryption key is in RAM.
Finding a dropped yubikey and immediately having access to someone’s google account is simply reasonably a bridge too far if that ever became commonplace. Someone decided not to allow that footgun to the public.
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.
> Finding a dropped yubikey and immediately having access to someone’s google account
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?
You should at least need the username but i still totally get the bar being set where it is.
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.
I always ask how you expect to defeat the vendor lock in?
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.
> 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.
the spec actually supports this, it's called caBLE
Right, that flow seems somewhat straight forward and is roughly what I had in mind with my sentence. It doesn't really break you out of vendor involvement, though? You both still have to be fully in on the whole flow. Right?
Asked differently, how does this get a vendor out of the picture?
caBLE is not a specification for transferring secrets, but for mediating (temporary) access to them.
But the FIDO alliance is apparently working on that: https://fidoalliance.org/fido-alliance-publishes-new-specifi...
I actually thought it was more for mediating confirmation of access to them. You don't share the secret with the new party, but you and the vendor both do a flow with them to confirm that someone claiming to be an identity can support that claim.
Do not use a vendor for managing passkeys. Use a self hosted password manager like vaultwarden. Or spin up an OIDC provider with pocket-id. Using a vendor is just pointless and should be avoided at all costs
I do that. Largely. I prefer hardware tokens.
I also have to confess this is clearly less convenient than having Apple or Google manage them for me.
The FIDO Alliance (who wrote the WebAuthn spec with the W3C) has a draft specification for a format (Credential Exchange Format) and protocol (Credential Exchange Protocol) for migrating passkeys and other credentials [1]. I don't think this is implemented by any providers yet, but it's being worked on.
[1] https://fidoalliance.org/specifications-credential-exchange-...
The big remaining issue in my mind is this one:
https://github.com/fido-alliance/credential-exchange-feedbac...
I am worried about providers blocking exports “because security”. That’s Apple’s favorite argument
On Android, Keepass2Android developer is working on supporting passkeys in the near future (https://github.com/PhilippC/keepass2android/issues/2099) but I'll be honest, I haven't dedicated enough time learning about passkeys to be sure the app will be able to support all implementations of passkeys and avoid vendor locking completely.
For me, the only thing that makes passkeys viable is backing them up in the cloud and automatically syncing them across devices. Otherwise, I do not trust them.
What do you use?
Not the parent, but the obvious answer is: a hard token (e.g. Yubikey). After all passkeys are just a software emulation of the smart card / FIDO2 mechanism that's been around for many years.
This doesn't solve the problem, unfortunately.
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...
It works well enough. When you need to signup for a new service on the go, you can add your backup key when you get to it. Having the backup key in a safety deposit box hardly accessible seems like a non-goal given you protect it with a pin with a very limited number of retries.
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.
I have three: 1) local usage 2) local backup key 3) remote backup key
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
This is the way.
> Having the backup key in a safety deposit box hardly accessible seems like a non-goal
It's absolutely a goal, since a PIN doesn't prevent your security key from loss, theft, or physical destruction.
I keep it in a secure separate location in case my house catches on fire.
I'm not sure if this is satire. You trust the "cloud" and whatever does the syncing to the cloud? I definitely don't trust anything that "syncs to the cloud".
I read their comment to be “I trust myself to lose a hardware key, but not a software key that’s backed up and synced across all my devices.”
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?
> I definitely don't trust anything that "syncs to the cloud".
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?
I use KeePassXC, and I have backups, if that counts, at least for passwords/passphrases and TOTP.
do you have offsite backups?
I do not have any backups on any servers, I have them on other media that I have physical access to.
It doesn't matter as long as it's encrypted. Use rclone crypt and upload to whatever "cloud" you want
If it is encrypted (incl. the filenames), sure, but is it usually the case? If I do it manually, of course it would be, but all these modern "sync to cloud" solutions, I absolutely do not trust.
Sure, why not? The cloud is just somebody else's computer, and if I don't trust that somebody to not take a peek, I'll make sure to encrypt my data first.
Many password managers do just that.
Probably not satire. He/she doesn't need you to trust it for them to use it.
1Password integrates with all pass keys on my iPhone, my Mac, and my Linux box.
By a far and away WORTH the subscription, for me!
doesn't that mean your passkeys are now about as secure as a regular password?
Passkeys are highly phishing resistant in a way that passwords are not and are not subject to credential reuse (though password managers somewhat solve the first problem and almost entirely solve the latter problem.)
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.)
How do Password managers solve phishing issues? Even just somewhat?
Your password manager will autofill your credentials on the real site but not on a phishing site.
Ah true. Didn't think of that. Good point
No. The service you are logging in to does not hold the keys so they can't be leaked, passkeys do not get reused between services, it's effectively impossible to fall for phishing attacks with passkeys, and it's effectively impossible to fall for scammers trying to get your keys since there isn't any mechanism to directly dump the private keys out.
Pretty much all the problems related to passwords are solved by passkeys, having them synced between your devices does not impact that.
A passkey is a public-private keypair strongly tied to a specific site. Sites never have access to the private key, and the key will never be presented for use on the wrong site. Those two advantages remain even if the passkey is stored in software or synced over the cloud.
That's my impression as well, and the nature of computing today /encourages/ putting passkeys into some container that means that they can be accessed from other pieces of hardware at different locations.
Don't know about you, but my passwords were already secure enough anyway.
From a practical perspective, passkeys are mostly identical to passwords where (1) secret generation is guaranteed to be strong, random, and unique; (2) they're tied to a specific site, so they can't be phished; and (3) filling is standardized and therefore ergonomic. If your passwords have those properties, passkeys aren't really an improvement for you. The main benefit to savvy consumers is that websites can trust that your passkeys are actually high quality and treat them as a primary authentication mechanism, instead of only a weak factor in an MFA system. And of course the huge huge benefit to most (unsavvy) consumers is that, you know, they're actually secure/unique and phishing-resistant.
Normal passwords can be phished, no matter how strong it is. The weak link is always a careless human. Passkeys are definitely a huge improvement for everyone, apart from the vendor-lock in which can be avoided
You can get around it, of course, but password managers are aware of the correct domain for a password and will only auto fill it into a form on the right domain. This is phishing-resistant. I'm not saying it's perfect, and I'm a big passkeys advocate. But "randomly generated password auto-filled by 1password" already meets many of the same benefits as passkeys, kinda, so long as auto-fill works on that particular website. Passkeys, in addition to stronger versions of those properties, also provide (1) ergonomics/standardization ("fill" works everywhere) and (2) sites can trust them to be strong.
Imagine using the worst password manager out there. 1Password was breached several times and even led to some people losing significant amount of money
Please do share some links to these events, because this is the first I hear of it.
Can you expand on the vendor lock aspect? I have stored passkeys in my password manager, so they feel pretty portable to me. Is it that each service requires a unique passkey? That seems comparable to how each service would require its own TOTP seed.
Your password manager came from a vendor. As a thought exercise, switch vendors.
Bitwarden exports include passkeys.
Have you actually tried exporting a passkey and importing it into another manager, then successfully authenticate with it?
KeepassXC lets you export the private key, which you can then back up or import into another KeepassXC instance. I have tested this, it works. I even shipped my exported private key off to a friend in another state and he was able to import it into a KeepassXC instance and log in to my account. Presumably another password manager could support importing the data, as it's just plaintext, though I don't know if any do.
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
Furthermore, they "heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers."
Basically, do what we say or expect us to have our corporate sponsors write bad press about your security.
BitWarden is OpenSource. I did try importing the export using my own hosted BitWarden server, it worked.
Just having the data exported is peace of mind for me. It's trivial to import or convert to another format (even if not implemented now), so the worst-case scenario is acceptable, especially considering how much better Bitwarden + Passkeys are to every other form of authentication.
https://blog.1password.com/fido-alliance-import-export-passk...
> we have no interest in creating a walled garden or locking you into 1Password.
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?
Maybe they can get more customers by being based.
I think you're thinking of incentive not interest. Like how you can have incentives to steal from the supermarket, but still have no interest.
I'm thinking of another definition of "interest". e.g. "have an interest in"
From the article:
> 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?
> Does anyone know the state of the standard wrt this?
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.
I use KeepassXC on my PC. Not sure of an app for mobile though.
Unfortunately I don’t think there’s much to help with vendor lock in directly (like, you may or may not be able to export the private key(s) depending on the tool, and in some cases it’s definitely not possible like with a hardware key), but any website that supports passkeys supports WebAuthn in general so you shouldn’t have difficulty migrating to another tool if desired, although you would need to register again.
Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service. Lock-in is built into the design.
One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
Attestation is probably the best feature of passkeys.
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.
This is fine for corporate settings, where the data is not owned by the user but by the company. But it's completely unacceptable for managing one's own personal account. What do I do if I do not trust proprietary software to manage my ability to log in to online services? How can this be compatible with open source passkey providers?
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.
Apple has stated very publicly and in multiple places/ways that Consumer Passkeys will never include attestation data on Apple hardware. That's not "the spec", but it is still currently a big enough moat to protect Consumer usage of passkeys away from Corporate needs, given most Consumer apps/websites probably want iOS/iPadOS/macOS (in decreasing interest) users today.
> Apple has stated very publicly and in multiple places/ways that Consumer Passkeys will never include attestation data on Apple hardware.
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.
Yeah, it's unfortunate we live in an age where searching for things is harder and less likely to turn up the results from even a couple months ago.
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.
Excellent writeup. This is the true kicker:
> 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.
Attestation is only about security if there are ways for people to handle it themselves. Think of them like certs where anyone can buy one or get one for free using lets-encrypt. I should be able to attest my own keys in a similar way. If I cannot then they are not really about security but about control and lock-in.
Attestation is probably the worst feature of passkeys.
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.
But most passkey providers don’t return attestation data. How do you get the data?
Attestation is not provided by the passkey provider itself, but the OS.
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...).
> Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service.
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.
This is largely a problem because the specification does not cleanly call these out as two completely different feature sets, e.g. via "profiles" or a similar mechanism.
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.
Yes, clearly separating these two use-cases would have helped immensely.
This technically is true because Passkeys are just a subset of WebAuth.
None of the common passkey implementations support attestation.
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.
https://github.com/timcappalli, "passkeys, FIDO2/WebAuthn, and digital credentials @ okta"
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...
https://strongboxsafe.com/
> Generally, authenticators are “something you have.”
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.
There was an interesting Kickstarter a while ago called DiceKeys https://www.crowdsupply.com/dicekeys/dicekeys that provided a physical mechanism to store the seed of a passkey.
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'
Why is it fundamentally a bad idea? Seems like a reasonably good idea to me.
The problem is that most humans aren't capable of remembering high-entropy passwords, and are even worse entropy sources.
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?)
> And if it is high entropy – where are you storing that in turn?
A password manager.
Neat project!
So how well do passkeys work when you don't sync passwords. When you bounce from machine to machine. From OS to OS.
How well does password recovery work in those scenarios?
This is a really common question but it has a really simple answer. They still have recovery methods. You can optionally change these with most providers (go into account settings, setup something like a recovery codes and check the option to be completely passwordless) but regardless they still have recovery methods. As in i lost my phone and i recovered the account with a combination of my secondary email and old password.
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.
Using CTAP2, you can authenticate a passkey on any Windows laptop. macOS also has decent support (though not as seamless if you're not using an iPhone because of course it isn't). I personally do it when I need to boot Windows for something, using the Bitwarden app to expose passkey logins to my laptop.
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.
Should allow multiple passkeys. So you have one per device.
That introduces new friction to setting up a new device, which is worse than the case with passwords.
You can use the same passkey for multiple devices (for example with keepassxc as authenticator that handles them), but it reduces security same as for example with using ssh private key that's not unique per device.
And if you don't use the same passkey, then you have to create more passkeys.
You should be able to revoke needed passkeys then. I.e. let's say you lost device A. May be revoke access for associated passkey for all places where you used it, but the rest of them would remain OK. Not sure how sites handle that (if at all).
It works great with physical keys. Just need one as backup you leave at home.
And you need to register for every new service you create an account with.
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.
Somewhat off-topic: Does anyone know the underlying strength of the keys used as the "root of trust" behind passkey synchronization on Android/iOS? I can't find a lot of documentation on this.
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?
A confidential channel can be established over an insecure medium using e.g. Diffie-Hellman key exchange. To protect against MITM, an out-of-band QR/bluetooth can be used.
Typically you see symmetric encryption keys (AES-256 is the most common), derived from a Password KDF. I don't know what Google or Apple do specifically, but that'd be my first guess.
I see everyone putting their TOTP and second factor in the same vault as their username/password. Doesn't this defeat the purpose of the second factor to some degree?
To me, this totally depends on your threat model.
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.
Exactly. The greatest risk to the average person is their credentials are obtained through a leak and 2FA helps mitigate that impact.
I know many people who still reuse passwords, which certainly have been leaked, and are probably protected only by 2FA.
Sure, but TOTP still defends against password leakage. So it’s still more secure than only using a password.
It definitely does. But many people don't want to use actual 2FA, or they don't understand the point behind it.
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.
Yes it’s then two step verification not two factor, a bit less secure but a lot more convenient (age old trade off between the two). The benefit you get compared to having only password is that it’s now time based instead of static.
It's about accountability sinks. The purpose of requiring the second factor is for the company to blame the user when the user gets hacked. It has very little to do with actual security.
With TOTP you have a private key that you don't transmit over the wire, as opposed to your password, so security is improved even though the password and TOTP is in the same vault.
Agreed Stefan! I keep mine in separate vaults for this purpose. I’m still not on board with passkeys yet, but the discussion here makes BitWarden seem like the best solution.
Are passkeys seeing any traction?
At the moment, I'm going to avoid them as long as I can. It's not that I don't like the concept, but I think that a strong password + 2FA is already "enough" and I don't need to add complexity to my setup. No, I don't really fear phishing.
Passkeys reduce complexity, at least in my experience. A single click versus entering credentials then finding the 2FA pin on your phone or something.
By "complexity" I meant that they are "opaque" to me and somewhat not tied to and identity (be it email or username). Maybe it's me being inept, but I used them once or twice just for fun in Bitwarden and now I can't find them anywhere in my vault.
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.
I've got no overall stats but they are very well integrated in to iOS. You could end up using them without really even knowing what passkeys are. Websites and apps just prompt you with "add a passkey" and if you hit accept you get one and it gets synced to all your other Apple devices and just works.
I don't use them much because I don't have a good way to register them and use them across device ecosystems. I use all three OSes regularly.
1Password and BitWarden both support Passkey sync across all three OSes. Though if you are using Android regularly enough that may imply you trust Google implicitly enough that you probably could also just get away with Chrome Passkey sync which I'm told also works on all three OSes today.
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.)
I guess I'm partially just stubborn because I don't want to pay for what should be a cross platform standard.
KeepassXC is a good client that lets you handle your data how you want. I wrote a pro-Passkey blog post here[1] that explains how to do your own syncing, though I later discovered Passkeys are explicitly built to support proprietary software vendor lock in and had to revoke my support. If you are concerned about being able to control your own data outside of the big tech ecosystem, I strongly recommend avoiding passkeys entirely. It is possible for now, but they are not built for that and the spec authors are actively hostile to you managing your own data.
[1] https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
That is what I've noticed as well. The thread regarding KeePassXC is crazy... straight up threatening negative PR because KeePassXC allows people to store their private key, demanding that they instead take away user choice and modify their app to hide & prevent users from doing things. Passkeys appear to me to be nothing more than a corporate gimmick, and to be honest, I personally think in many instances they actually make you less secure... getting a fingerprint is way easier than making someone tell you their password. Now days the intelligence agencies likely already have your fingerprints as well.
They're a great technology that the FIDO Alliance is trying their best to cripple.
I also meant to mention that many Keepass clients support Passkeys already today. Strongbox on iOS and macOS has similar or better integration to 1Password/BitWarden. Windows you probably want KeepassXC for now as it isn't fully baked in mainline Keepass. I don't know what you'd use on Android today, but I'm sure there's at least one and probably more on the way.
Bitwarden is free, and if you are concerned about these terms changing, the excellent self-hosted open source server implementation "vaultwarden" [1] supports passkeys as well.
[1] https://github.com/dani-garcia/vaultwarden
The Google / Chrome sync is free
Free != standard.
I've used them across Chrome, Firefox, and Safari on Linux, macOS, and Windows (10 and 11) for large websites. I've used them for Github, as 2FA on various services, and as the primary login for some websites, such as the local grocery store (Albert Heijn). I also use them for authenticating to my personal Keycloak server which acts as a guard for a whole bunch of services in my network.
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).
They are still not implemented in major browsers and operating systems (e.g. Linux Chrome), so not likely much traction.
This is a straight up lie. They've been in Linux Chrome for quite some time now.
This is a straight up lie. Here's a screenshot from my PC: https://0x0.st/8v8T.png
Not implemented.
Google documentation states in multiple places that passkeys are supported in chrome Linux via google password manager. I haven't tried myself, are you saying that is incorrect?
Yes/no. I have a few passkeys in my vault but several are for different accounts with the same company (e.g. Amazon, Google). I expect adoption to continue but will take years.
I hope 1Password release passkey unlock for vaults soon. Then I'll never have to enter the passphrase to unlock again, and my "passphrase" will be essentially the unlock code for my phone.
You can already unlock 1Password using biometrics in your Apple devices. they do ask you for your password every 2 weeks though. But I think that's a great balance.
...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.
With a passkey you would have one in keychain that unlocks 1p. So you will only be asked for your phone password/unlock code whenever iOS asks, but it will be used to unlock 1P. Never need to enter your 1P passphrase.
I still don’t follow. So instead of 1 password that you remember, there would now be a passkey?
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.
The passkey is stored in the secure enclave which is protected by your unlock code & biometrics (for fast unlock), or whatever the equivalent is for Google. You're not replacing your secret key / passphrase, it's just a different way to authenticate and decrypt vaults.
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.
Yep
Why does a browser have to be in the loop?
Because the browser knows the internet domain that the login/registration is for. And the browser also provides the JavaScript API to talk to the authenticator (navigator.credentials.create and navigator.credentials.get).
Have a question, is the TLSSessionState part of the signature nonce?
I remember this being an anti-MITM measure for u2f
My friend asked similar question yesterday, and while I don't know the answer I wish it don't
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.
Damn, I didn't of that. Yeah, Cloudflare is [technically] a [friendly] MITM attack. Didn't think of that.
Passwords and password managers seem good enough to me, and TOTP support is everywhere now.
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.
Password/TOTP does not protect you against phishing. The phishing site can forward the password and TOTP you type into the real system, gaining your access.
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.
Considering there's an entire portion of the software industry built on accepting a user's credentials and also prompting them for their TOTP, I don't think this really matters.
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.
> The phishing site can forward the password and TOTP you type into the real system, gaining your access.
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.
If you're targeting a particular person, social engineering is probably easier. If you just want to illicitly harvest some accounts, and aren't too worried about which ones, blasting out emails linking to hacked websites that fake the login & TOTP flow is very easy.
A couple years ago there were several posts here about not using PassKeys, and I went along with that for a bit. But I’ve fallen in love with them. They’re so nice to use with 1Password.
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.
> 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.
This is crazy and should be outlawed. Honestly, it's so annoying...
I get the security behind email-only sign in, but waiting on mail servers is so slow!
Passkeys are honestly the most frictionless system. No more waiting for 2FA codes and having to type them in. No more getting locked out of your accounts if you lose your phone.
With Bitwarden the 2FA codes are copied automatically to the clipboard, being thus just a "ctrl+v" away.
Passkeys are fantastic! I encourage my family and friends to utilize them as an alternative to passwords whenever possible.
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...
> 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.
I love being able to use my Yubikey instead of a password. And I don't feel I'm locked in then...
Passkeys are an API that requires the use of a password manager. It doesn’t lock you into any hardware any more than your password manager does already.
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.
I use Yubikeys as my passkeys, and in terms of security it's strictly superior to passwords.
> 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?
Challenge-response with asymmetric encryption is pretty much perfect. I wish all auth worked like SSH.
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 implemented passkeys @ $WORK, and we rolled it out to our tech department only first. Nobody could make it work reliably, and troubleshooting it was basically impossible. The best you could do was just wipe their passkeys and have them try again.
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.
The problem with TOTP is that it isn’t a second factor. It’s like Kerberos for the web. Passkeys are similar, only allow hardware devices with PIN.
Regardless, TOTP is way better than passwords alone, or SMS as another factor. It's also the only one that can be deployed at scale that is supportable.
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.
How is it not a second factor ?
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 ?
Passwords are "something you know". TOTP is "something you know". It wanted to be "something you have", but it's not. Proof: I can put TOTP tokens into my password manager now. Anything that can go into my password manager is proved to be "something I know" by the fact I can put it into my password manager.
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.)
Isn't it the same for passkeys? I can put passkeys in password managers like Bitwarden, 1password, ...
Yes. Passkeys help with the bad password problem. That’s a big deal but doesn’t magically solve everything.
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.
Within the larger spec, you can whitelist a set of known devices, such as only allow Yubikey's, etc. Which would prevent the private key material from getting into your password manager.
You can but the server can require an device attestation during registration, proving that you're actually using an Yubikey or whatever. That isn't possible with TOTP
> > Incidentally, passkeys go into my password manager too. You can probably work the math from there.
Incidentally, biometric scans can also go in password managers. Turns out it's all just bits. Who knew?
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.
I think you're all missing a bit of the point.
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.
> > it's all better analyzed in terms of the cost of knowing and proving knowledge
It’s a second password - not a bad thing, but still vulnerable to many categories as attacks.
totp is not a second password, it is immune to data/password leaks because it expires quickly
Not really. You just need a working clock and the string. Conveniently available in your password manager.
Same with passkeys when you think about it. Just need the private key.
For fingerprints/etc you generally just need a great camera.
I haven't had any problems with syncing and using passkeys with 1Password and Firefox on MacOS, iOS, or Windows. When the site wants to create or use a passkey I get a prompt from 1Password on the device that I'm using. No need to involve a second device (which for me I'm fine with security-wise. If I really wanted to be sure there was no way of malware extracting the keys I would be using my Yubikeys)
What kind of Mac and what version of MacOS?
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.
FWIW, I migrated to ed25519-sk SSH keys backed by FIDO2 credentials on my Yubikeys, and I really love it. The fact that my credentials effectively can never be lifted out of my hardware key is quite comforting.
Look at KeepassXC, they let you do backups.
Is there a "platform authenticator" that allows import/export of the actual origin site, keypair, and credential id in plaintext? The next would be a variety of platform authenticators able to import and use those?
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.
KeepassXC allows this, but the spec authors think this is bad and have threatened KeepassXC with being banned by authenticating websites. The spec has explicit support for banning clients built in. https://github.com/keepassxreboot/keepassxc/issues/10407
Some open source password managers provide this, but the general industry is working on a way to transfer between hosts without having to dump everything out in plain text in between.
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
Passkeys live at the OS level not the app level. If they have a passkey that allows access to their Google account the passkey will still be there if they uninstall Youtube.
Passkeys don't live at any particular level. They can 'live' on a piece of paper, and get lost from wherever they are stored.
I wouldn’t group app authentication like that with normal passkeys that are stored elsewhere.
I wonder which authenticator was used in this case (YouTube app). Was it an authenticator that was part of the OS or something else?
I believe the complaint here is that the YouTube app on iOS is an Authenticator for Google Accounts today. I didn't know it was doing anything Passkey-specific on iOS, but that wouldn't shock me given all the other ways it currently is the de facto Authenticator app for your Google Account on iOS today.
Google is basically just using the YouTube app as a second factor.
[flagged]
Or an investment, like VTSAX