Comment by BadBadJellyBean
8 days ago
You can put your passkey in another safe. I store mine in my vaultwarden. You can also do keepass with a plugin. You don't have to store it on your phone.
8 days ago
You can put your passkey in another safe. I store mine in my vaultwarden. You can also do keepass with a plugin. You don't have to store it on your phone.
There is no truly secure options for this, unfortunately. Passkeys have to be online to enroll additional keys, so any kind of software or smartphone solution is going to depend completely on cloud sync. Any form of offline copy stored in a physical safe will quickly be outdated.
It gets even worse when you want to have separate passkeys, so that you have the possibility of knowing which one was compromised and doing a partial revocation: the cloud sync now requires every device to have access to every copy, so that you can individually enroll them during registration.
Yubikey of course suffers most from this, as their hardware tokens are physically incapable of any kind of sync, so a Yubikey passkey is very quickly a single-point-of-failure. They proposed[0] a system which would allow enrolling a "backup key" (which could then be safely locked in a vault, far away from day-to-day use), but with the various Big Tech companies pushing their own proprietary cloud-synced passkey implementations that of obviously went nowhere.
[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
> Passkeys have to be online to enroll additional keys
No they don't? A passkey is fundamentally just a private key pair, which can be copied around just like a very long password. Of course if you store it inside one hardware enclave and want to move it to another hardware enclave you have a problem, but for software implementations it's simply a client UX issue.
I think "online" here means "loaded in a device", as opposed to "sitting in a safe".
The protocol requires additional keys to sign a challenge during registration, so at best you have to load a pre-generated key from the safe when creating a new account. In practice, you generate a new key for every account, so between generating the key and storing it in your safe there's no backup but cloud sync.
This prevents using backup storage that is safer but inconvenient to access, and also prevents registering accounts on-the-go.
7 replies →
Most website implementations that support passkeys have to support multiple key enrollment. It's the only long-term reliable way for the many, many users that are cross-ecosystem, which especially means Windows users in the age of no Windows Phone. Every Windows user has either an Android or iPhone. You can bootstrap with Bluetooth LTE access to your phone for a Passkey, but it's a rough web experience if the user needs to do that every time they access a page, so most good flows ask the user the enroll a Windows PC passkey in addition to their phone's passkey and really good ones make use of a passkey auto-enrollment option designed for this scenario (Bluetooth passkey to "local" passkey auto-enrollment).
Perhaps surprisingly, Windows has helped keep Passkeys from being "proprietary" lock-in because Microsoft no longer has users in a single ecosystem.
There is no dedicated auto-enrollment for "backup" keys, but most consumer sites make it very easy to enroll "backup" keys yourself.
Also, Passkeys don't have to be "online" to enroll additional keys. Each key is independent, enrolling is just generating new keys. The trouble is that web browsers generate lots of Passkeys (at least one per domain, at the very least) so if you in theory want to print them all and store them in a physical vault it might be a hefty book you are printing.
Cloud sync isn't required. Most users want it so that they don't have a single-point-of-failure.
As an implementation detail some Passkeys have a master key that is then used in some key derivation function (KDF) to generate the hundreds or thousands of individual passkeys (at least one per domain), and that's what most Yubikey passkey implementations need to do because Yubikeys weren't designed to store lots of keys, so it is devices like Yubikey that makes it seem like Passkeys are less independent than they really are.
I am not sure I completely understand.
> so a Yubikey passkey is very quickly a single-point-of-failure
It is a single point of failure when there is one. As soon as you use two, then it's not a single point a failure anymore, is it?
The counter argument I usually read is: "Yeah but it is not practical, because you need 3 yubikeys: the first 2 with you, that you enroll everywhere, and one in a safe. And every time you add a new passkey, you need to go get the one in the safe, replace it by another one, and enroll the one of the safe. You can't spend your life driving between your desk and your safe".
But I have been using multiple Yubikeys for... 8 years now I think? I don't remember the last time I enrolled and important key. Sure, once in a while I add a website, and it is a bit annoying to have to enroll the other Yubikeys at a different time. But it really doesn't happen that often, and anyway most of those websites allow me to recover my account with my email. So it is actually practical to have a "convenience yubikey" for websites that don't matter so much, and in case this Yubikey dies... well those websites were not so important, and anyway I can recover from my email.
The difference for the important websites (and really, I don't think I have really important websites in my life that don't allow me to recover by going in person with my ID, but for the sake of the argument) is that I actually do have multiple Yubikeys, one of which is stored away.
Whereas the master password of my Bitwarden account is a single point of failure, and the security of my online Bitwarden account is as well.
That's a clever setup that I hadn't seen before. Some extra downsides:
- Relying on emails for account recovery prevents creation of anonymous accounts.
- Have you ever lost your "convenience yubikey"? People underestimate how painful mass account recovery can be.
- The cost of 3 yubikeys can be substantial for some demographics.
- Important accounts are not properly backed up until you drive to your safe. That can be many days for a bank deposit box, or even longer if you're traveling.
Overall that's a lot of compromises for what should have been just "put this recovery key/password in a safe and forget about it until needed", if the protocol was better. And definitely not something that can be widely recommended.
7 replies →
> I have been using multiple Yubikeys for... 8 years now I think? I don't remember the last time I enrolled and important key.
This probably makes your use case somewhat unusual...
> I actually do have multiple Yubikeys, one of which is stored away.
...and this probably puts you in the 0.0001th or so percentile of users. It's really a great security strategy if you can pull it off, but practically almost nobody can.
2 replies →
I use Yubikeys for WebAuthn 2FA (not as passkeys). Keeping them in sync is not a big issue in practice: I just don't sign up for new services that often. There's a stable set of services I'm using and it is rare that I actively look for something new. Usually it is the other way around--how do I use this thingamajig without creating an account.
Why would cloud sync never be "truly secure" (no such thing btw – security is always a tradeoff, availability also matters etc.)? A hardware root of trust and credential synchronization are not mutually exclusive.
True, most solutions today don't do this, which makes onboarding of fraudulent additional instances to some cloud-synced vault a big security concern, but I don't think it's fundamentally impossible.
Not mutually exclusive, as long as you have a trusted mechanism for establishing mutual trust between hardware roots. How do you achieve this when one of the roots is a distributed cloud service, provided by a third party?
A cloud synced passkey is still better than a cloud synced password, and that is the alternative.
> You can put your passkey in another safe.
This! Passkeys would have been tough for me to adopt without this ability. Now passkeys are significantly more convenient that any other MFA method.
Right, but... I can already store my credentials in a password manager and enable MFA. I understand the pitch, but Passkeys seem to buy me very little as a user and add significant brittleness.
Most password managers allow passkey creation and storage. Most cyber attacks these days are initiated by phishing. If you get hammered one night and open a bogus link, you can still complete the pass/OTP combo, but a passkey will simply refuse to sign a domain that's not tied to
> I store mine in my vaultwarden.
Can you export it from there? My main gripe with passkeys in 1Password is that seemingly you can't export them, unless you export it to "someone else", which isn't clear if that someone can be just "you".
If your password vault supports https://fidoalliance.org/specifications-credential-exchange-... you can. (Bitwarden does)
No, if your vault implements that then it can _not_ export to the user, as per §5.1.1.1:
And, in accordance with the spec, 1Password (who is the _editor_ of that spec) refuses to export passkeys to the user in any file format.
Right, what if I don't know yet what password manager I want to move to? Can I just get the data or I'm only allowed to move this thing into something else I also don't actually own?
3 replies →
Yes. I've done many imports/exports and have lost no passkeys with Vaultwarden.
Yes you can. I just tried it and it worked. I used the export functionality and exported my vault as json and the passkey is in there.
I do not know the answer to your question but mine are in Vaultwarden. This probably means I have access to them. The method to get them out might end up not being pretty but it should be possible.
> but it should be possible.
This was my expectation too, but since I haven't figured out 100% that it is actually possible, I haven't used any of it.
You can export them to Bitwarden and then export those to a file.
I agree that is annoying.
What if they meant a real safe? The big metal kind.
Passkeys are just a private key plus some metadata.
Bitwarden lets you export your vault, and the export contains the private key in plain text. There is virtually no difference to writing down a password on a piece of paper. Well, I guess a passkey is a lot longer than the avg password.
This changes if attestation ever becomes widespread. Which will only happen if Apple does a U-turn on their stance.
> There is virtually no difference to writing down a password on a piece of paper. Well, I guess a passkey is a lot longer than the avg password.
The big difference is not just that a passkey is a private key, it's that the server you register the passkey within holds only the corresponding public key. They don't have a copy of your password (long or otherwise), not even a hashed version of it that could be recovered from a password database dump of the server.
This is a big improvement compared to the days of having your "strong password" end up on the dark web somewhere.
1 reply →
Bitwarden is the only vendor I'm aware of that currently allows this, and it wouldn't surprise me if their new management takes this away in the medium term.
The FIDO alliance is trying very hard to squash any workflows that a scammer can use to convince an elderly retiree with $1mil in savings to wire their life savings to Russia. Unfortunately, nearly all of the export paths that we want as hackers overlap with these attack vectors. The drafts of the Credential Exchange format or Protocol assume that end-users and open-source tools are not valid targets.
2 replies →
There are many hardware keys that support webauthn, like YubiKey.