Passkey vs smart use of passwords
I went down the path of thinking about switching to Passkeys but it seems like more hassle than it is worth, so I hoped this community could tell me if I am crazy.
I use Bitwarden to generate and save passwords for anything important and always use an authentication app when the option is present. I never use the same password. Sadly, most Canadian banks are awful and only allow SMS 2FA if anything at all. That said, of the two banks I primarily use, one does allow an authentication app and the other uses its own app to send authentication codes.
I always read that Passkeys are better for people who are lazy/bad with their passwords. For someone like me, is the security practically the same or is there still some benefit to switching everything I can to Passkeys?
I've been trying to figure out how passkeys work under the hood. That's proving a bit difficult since most information about them is focused on informing users about how easy they are to use and how passkeys make it look like you're logging in with you fingerprint or facial recognition. But here's the big benefits from what I've been able to gather:
Longer term, passwords are going to have to be longer and longer as computers get more powerful. Eventually they’ll have to be so long that we can’t be expected to remember them (though I have no idea what the projected timeline on this is). Getting people to use a password manager isn’t really an option - people see all of their passwords in one place and can’t believe it’s secure. Passkeys are a potential solution for this. Using public key encryption is an added benefit that makes them even better than long passwords.
Important additional benefit that is missing in your otherwise excellent explanation:
Passkeys also inherently function as a multi-factor tool. You prove who you are (through biometrics) or prove what you know (through pin) and since the key is device bound you prove what you have (physical access to the registered device)
This makes passkeys inherently more secure than passwords.
Biometrics aren't something passkeys inherently do, since passkeys are just an API and password managers work in different ways. It's something that devices such as mobile phones can do. You can decide what kind of screen locking to turn on - fingerprint sensor, entering a pin, or something else. A password manager could also do a biometric check before filling in a password.
Passkeys functionally enforce MFA, which is what polle is saying. They just used biometrics as an example of an additional factor since they are borderline ubiquitous on both smartphones and laptops these days.
Passwords don't actually need to get longer as computers get more powerful. This is based on the idea that stronger computers can more rapidly attempt brute force, but in practice they'll just run up against rate limit throttling far before that is ever a concern. Even with no explicit rate limiting just about any machine can already generate new passwords to submit faster than the network would support.
The only case that a longer password helps against a more powerful computer is if the hashed db itself is leaked and attempts to break in can be run locally on unthrottled hardware. Longer passwords are good, but unless you're assuming that your hashed password has leaked (along with any other relevant bits, such as the salt) then a faster computer won't do much.
The concern isn't faster and faster computers guessing passwords and plugging them into a login form. As you point out, that is a solved problem.
The concern is that a malicious actor who manages to steal a database containing hashed passwords can use a fast enough computer to randomly guess passwords until it produces a matching hash. Then they only needs to make one actual attempt to authenticate against the service, since they already figured out the users password "offline".
You can partially mitigate this by "salting" passwords before you hash them. This is where you append some pre-defined string to user passwords on both account creation and authentication, before it is hashed and stored in the database. But this isn't perfect. If an attacker has gained access to your database there's a non-zero chance they also have your salt string, since your app can't effectively use this strategy without knowing the salt string itself.
This is why everyone is moving to public key cryptography, which is what passkeys are built on. Unlike with salted hashes, your app doesn't need access to any user secrets at any time in order to authenticate them. Those secrets can stay entirely local to the user's device
Knowing the salt shouldn't actually help an attacker very much. In a scenario where a database is dumped, the attacker still needs to try every password manually to find the corresponding hash and password. The goal of salting a hash is to defeat rainbow table lookups. As long as your salt is unique, it still manages to accomplish that goal.
That's what I said though. Assuming that passwords need to get longer as computers get faster assumes:
In practice it generally will be far more effective for the service-side to switch to more computationally expensive hashing algorithms as available hardware gets faster than for users to use longer passwords. Depending on the algorithms used they may even be able to get away with just increasing the size of the salt.
I also wasn't really trying to say anything about passkeys. I was specifically referring to the claim that passwords would need to get longer as computers get faster.
I do think its a bit misleading though to say "everyone is moving to public key cryptography". Some are, some aren't. There are a slew of other usability concerns that make me skeptical we'd see general consumer applications that are passkey-only any time soon, which just leaves the passwords sitting there as a threat vector anyway. As an example, lets say iOS hosts all your passkeys on your phone and you lose your phone. You get another and try to sync them again from iCloud and to do this you either need your passkey (whoops, its gone!) or a regular old Apple password that could have been breached like any other.
All of these points made me want to uses them now, so excellent overview of what is achieved security wise via passkeys.
But I remembered 2 issues in the KeePassXC repository on github:
Which to be fair are 2 points that probably was needed to be discussed, not for the problems they seems to represent for some people in the PassKey Initiative, but more importantly for these points:
So there seems to have a real risk of having the passkeys we setup be "revoked" or refused at any unknown moment when a website decide that a certain passkey provider is not "secure" enough for their taste.
This seems rather dangerous to begin to use them now :/
But they're perfectly happy with a situation where access to a single device grants access to every site?
Sorry for necroposting. This is the best and most compelling and simplest explanation I've read. I will start using passkeys.
Thank you for the detailed but not sales-y write-up.
Appreciate the write up!
I'm in much the same position as you. I use Bitwarden with a 20+ character randomly generated password for just about everything.
As far as I understand, the main benefits and reasons passkeys are being pushed are
#1 is irrelevant for people like us already using good practices and #2 is also less of a factor for people being careful. I don't want to say #2 is irrelevant because we're all human and we can all make mistakes.
There is another thing passkeys can do that I think could be useful to people like us but I don't see it talked about as much - passkeys can be used to sign in on nearby devices.
Basically, if you have a passkey for an account on your phone and you want to sign in to that account on a computer, the computer can connect to your phone and use the passkey to sign you in without you having to manually enter any credentials. While I don't see myself needing this often, the times I do it will be really nice.
Yeah I guess I just wanted to make sure I wasn't missing anything with my assumptions. Thank you!
If BitWarden is working for you, I don’t think you need to do anything? It might be useful for avoiding SMS authentication if a website offers passkeys as an alternative. But support for passkeys isn’t widespread yet.
There’s a slight advantage to passkeys if a website you use gets broken into: since they use public key encryption, you won’t need to change your password.
Also, someday, new websites might be able to rely on passkeys only, and then they wouldn’t need to store passwords at all.
Thank you. I wanted to make sure there wasn't some obvious hole in my logic I was missing.
I view Passkey as cutting out the middleman. If you can store very long passwords and OTP in password manager, why not just let the password manager securely authenticate you to the server directly.
The other benefit is that many passkey implementations also skips the username or password prompt, or both. I think in the specs the website should be able to ask your password manager to reauthenticate you (i.e. reenter the unlock key, or biometric) then the site can believe that the process is already 2 factors (you have the password manager access + you know the unlock key or biometric) so it can skip prompts for both factors. In KeepassXC it doesn't do that and it lie to the websites that you already did that so login become just approval click. Afterall, if it doesn't lie one could modify the open source app to lie anyway so might as well take the way that allow for user freedom.