Why passkeys are a step back for personal security: examining account lockout risks, platform lock-in, hardware key limits, and fragile recovery flows.
I feel like there’s some potential in password-derived passkeys, which would get around the storage and hardware lock-in issues. It’d essentially be a master password like for BitWarden, but instead of needing an app to store a bunch of generated passwords, the master password could be all you need to authenticate.
Most of the sources of compromise for regular users would be eliminated because the password never leaves the client.
Bitwarden lets you store passkeys in its vault, which I think is what you’re asking for? It’s mentioned in the post too.
I have some passkeys in my Bitwarden, and my Bitwarden account is protected with a USB + NFC Yubikey.
The experience is inconsistent across phone platforms at the moment, but it works great on computers. On Android, it currently only lets you use a password manager if the passkey is your primary credential for logging into the site. Android doesn’t support passkeys from password managers for 2FA yet.
What you are proposing is no different from using a password and wrapping it in custom transport security to send it to the server. This would result in everyone simply using the same password for all sites.
In the scheme I’m proposing, the password never gets sent to the server.
The issue of password reuse is the password getting sent to the site, because the prevailing approach is to hash the password server-side. Passwords leak because they get stored in plaintext, or hashed using outdated algorithms, or get logged with request metadata–bottom line, they end up stored somewhere that an attacker can get their grubby little paws on them, or in a way they can reasonably recover them.
Using a master password to derive a passkey client-side isn’t any different than using a master password to unlock a password manager. It just cuts out the middle step.
It’s not a bad idea but that idea breaks as soon as you have to change the master password. You would have to change every one of those passkeys. Which could be annoying, if you have a lot of them.
You might like the current implementation of bitwarden passkeys. You have the master password to unlock your vault of passwords and passkeys as per usual, but then the webpages connect with the extension to authenticate via passkey, so there’s no weak link where the password is sent, but changing the master password doesn’t affect all your other passkeys afaik.
I do not like the idea of password-derived
Passkeys, because then acquiring the password is once again all an attacker needs.
Passkeys work now because the device itself is the second factor, the “something you have”.
It’d essentially be a master password like for BitWarden, but instead of needing an app to store a bunch of generated passwords, the master password could be all you need to authenticate.
This exactly how the flow works with Bitwarden now; I’m not understanding how your system makes any changes other than how the passkey is derived.
In fact, that makes things less secure for two reasons: if attackers learn a master password, they can derive other passkeys from it for other sites even if they cannot access the vault (not possible with current passkeys) and if you want to change your master password, all your derived passkeys become invalid and need to be regenerated.
The return of SASL DIGEST! (Or these days probably CRAM or SCRAM)
But yeah, the “hard” part would be that you don’t want the user to type in a password to the website because it could get snatched, so you’d want the User Agent to pop up a password prompt, you type it, and then it does the hashing etc internally and only dumps the hash into the request. So you’d still need some kind of standard for that.
Which is basically just HTTP auth from the 90s. So the good news is that’s always been possible, and already has broad support and works with all browsers! 😛
I feel like there’s some potential in password-derived passkeys, which would get around the storage and hardware lock-in issues. It’d essentially be a master password like for BitWarden, but instead of needing an app to store a bunch of generated passwords, the master password could be all you need to authenticate.
Most of the sources of compromise for regular users would be eliminated because the password never leaves the client.
Bitwarden lets you store passkeys in its vault, which I think is what you’re asking for? It’s mentioned in the post too.
I have some passkeys in my Bitwarden, and my Bitwarden account is protected with a USB + NFC Yubikey.
The experience is inconsistent across phone platforms at the moment, but it works great on computers. On Android, it currently only lets you use a password manager if the passkey is your primary credential for logging into the site. Android doesn’t support passkeys from password managers for 2FA yet.
No. I’m talking about using the password to directly derive the passkey. This would eliminate the need to store them in something like BitWarden.
What you are proposing is no different from using a password and wrapping it in custom transport security to send it to the server. This would result in everyone simply using the same password for all sites.
So…re-using the same password for every service and site?
Grandma, that’s enough internet for today, OK?
how old is your grandma?
Would be 100 right now if she had led out for a few more months.
at that age just knowing what a password is already a triumph
In the scheme I’m proposing, the password never gets sent to the server.
The issue of password reuse is the password getting sent to the site, because the prevailing approach is to hash the password server-side. Passwords leak because they get stored in plaintext, or hashed using outdated algorithms, or get logged with request metadata–bottom line, they end up stored somewhere that an attacker can get their grubby little paws on them, or in a way they can reasonably recover them.
Using a master password to derive a passkey client-side isn’t any different than using a master password to unlock a password manager. It just cuts out the middle step.
It’s not a bad idea but that idea breaks as soon as you have to change the master password. You would have to change every one of those passkeys. Which could be annoying, if you have a lot of them.
You might like the current implementation of bitwarden passkeys. You have the master password to unlock your vault of passwords and passkeys as per usual, but then the webpages connect with the extension to authenticate via passkey, so there’s no weak link where the password is sent, but changing the master password doesn’t affect all your other passkeys afaik.
I do not like the idea of password-derived Passkeys, because then acquiring the password is once again all an attacker needs.
Passkeys work now because the device itself is the second factor, the “something you have”.
This exactly how the flow works with Bitwarden now; I’m not understanding how your system makes any changes other than how the passkey is derived.
In fact, that makes things less secure for two reasons: if attackers learn a master password, they can derive other passkeys from it for other sites even if they cannot access the vault (not possible with current passkeys) and if you want to change your master password, all your derived passkeys become invalid and need to be regenerated.
The return of SASL DIGEST! (Or these days probably CRAM or SCRAM)
But yeah, the “hard” part would be that you don’t want the user to type in a password to the website because it could get snatched, so you’d want the User Agent to pop up a password prompt, you type it, and then it does the hashing etc internally and only dumps the hash into the request. So you’d still need some kind of standard for that.
Which is basically just HTTP auth from the 90s. So the good news is that’s always been possible, and already has broad support and works with all browsers! 😛