Why passkeys are a step back for personal security: examining account lockout risks, platform lock-in, hardware key limits, and fragile recovery flows.
Well, she also had terrible dementia for years, so the only passwords she was going to remember was the Little Orphan Annie secret code of “Drink More Ovaltine.”
My MIL is a grandma, and I would give her a 75% chance of reading her passwords to “someone from the bank” if they caught her at the right time. Maybe she’s already done that, I’m not sure if she did that or almost did that once.
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.
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
Well, she also had terrible dementia for years, so the only passwords she was going to remember was the Little Orphan Annie secret code of “Drink More Ovaltine.”
My MIL is a grandma, and I would give her a 75% chance of reading her passwords to “someone from the bank” if they caught her at the right time. Maybe she’s already done that, I’m not sure if she did that or almost did that once.
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.
Ah, gotcha.
So, basically a biometic key, but with a password? Isn’t that basically just a self-signed certificate, then?