Passkeys are an easy and secure alternative to traditional passwords that can help prevent phishing attacks and make your online experience smoother and safer.
Unfortunately, Big Tech’s rollout of this technology prioritized using passkeys to lock people into their walled gardens over providing universal security for everyone (you have to use their platform, which often does not work across all platforms). And many password managers only support passkeys on specific platforms or provide them with paid plans, meaning you only get to reap passkeys’ security benefits if you can afford them.
They’ve reimagined passkeys, helping them reach their full potential as free, universal, and open-source tech. They have made online privacy and security accessible to everyone, regardless of what device you use or your ability to pay.
I’m still a paying customer of Bitwarden as Proton Pass was up to now still not doing everything, but this may make me re-evaluate using Proton Pass as I’m also a paying customer of Proton Pass. It certainly looks like Proton Pass is advancing at quite a pace, and Proton has already built up a good reputation for private e-mail and an excellent VPN client.
Proton is also the ONLY passkey provider that I’ve seen allowing you to store, share, and export passkeys just like you can with passwords!
See https://proton.me/blog/proton-pass-passkeys
#technology #passkeys #security #ProtonPass #opensource
But authentication to access the passkey is on a remote device. So the server doesn’t have any information about if or how authentication was performed for the person to access the key. If they use a 4 digit pin or, worse, the 4 point pattern unlock, it’s easy enough to brute force on most devices.
This is also why using a password manager is not two factor authentication. It is one factor on your device and one factor on the server. But no one monitors the security logs on the device to detect brute force attacks and invalidate keys. Most don’t even wipe the device if the pin is being brute forced.
None of what you’re saying has anything to do with whether an authentication flow is effectively implementing two-factor authentication.
The server doesn’t need to know details about which two factors you used. If you auth with a passkey and it knows that passkeys themselves require an additional factor to be used, then it knows that you’re using 2FA.
If they use a 4 digit pin or, worse, the 4 point pattern unlock, it’s easy enough to brute force on most devices.
This is true, but that doesn’t mean it doesn’t qualify as an authentication factor. Nobody should use a 4-6 digit PIN for their phone, but this is a matter of individual security preferences and risk tolerance. In a corporate setting, the corporation can set the minimum standard here in accordance with their own risk tolerance.
My password could be “password123” and it would still be one factor.
I’m not saying it doesn’t count as authentication, it just doesn’t count as authentication to the security of the server directly. That’s the device’s security and configured by the user, not the server. And user devices are very prone to exploits to the point that many law enforcement agencies don’t even bother asking for a password anymore to access a device.
So, let’s move to a physical model as an example. Let’s say you have a door. It has a very simple door handle lock. You keep your key inside a hotel safe. Sure it might be difficult to get the key if they had to enter the hotel room, cut open the safe in place, and get the key while they’re standing in front of the secure door, exposed. But that’s dumb. They could just as easily grab the safe out of the room and open it later where there’s room for proper equipment, use a known exploit for the particular safe, or use other exploits all out of view of the door/server and at any time until the user realizes you know how to open their safe, because the door/server will never find out. Once that safe is open, you have not just the key to the door, but the key to all locks the user uses since now we only have “something you have” factors and the user uses only one device. Just like when we only had “something you know” factors and the user uses the same password everywhere.
So what does the passkey help with? It makes the lock and thus the key itself more complex. This makes it so that brute force attacks against the server are more difficult. But it doesn’t solve anything that existing TOTP over text messages didn’t solve, other than some complexity, and it eliminated the password (something you know) factor at the server. Something a lot of companies are already doing and we already know from experience is a bad practice. It has changed the hacking target to the device rather than the person. But still just one target, you don’t need both. Sure it’s better than a really bad password that’s reused everywhere. But it’s not better than a really good password unique to a site that’s only stored in a password manager on the user’s device that requires a separate master password to access (outside of MitM attacks that TOTP mitigates).
Now, what if we have a door with two locks, one that requires a code, and one that requires you to have access to a device. Now in order to attack the door, you need two factors right at the time you’re standing at the door. Also, there’s probably a camera at the door and someone paid to check it periodically when someone tries too many times, which isn’t the case in the user’s safe/device. So even if you get the key from the user, you still need to brute force the second lock efficiently or you need to implement a second exploit to get the second factor ahead of time. This is the idea of two factors at the server and the current state of things before passkeys.
Getting physical access to users’ devices is more difficult than compromising their passwords, so in that sense, transitioning that one factor is a net improvement in terms of reducing the number of compromises for a given service.
Except for e2ee accounts, which I suspect Passkeys don’t support in the first place (at least, not without caching the password on your device), law enforcement can access your account’s data without ever needing your password. If you’re concerned about law enforcement breaking into your device and you’re not using a unique 16+ character passcode with it set to wipe the device after a certain number of attempts, that’s on you.
I’m not sure about the state of affairs on Android, but the most popular and powerful tool used by law enforcement to extract data from iOS devices only recently gained support for iOS 17 and it doesn’t have the ability to bypass passwords on a device that isn’t accepting FaceID; it just has the ability to brute force them. A password with sufficient entropy mitigates this attack. (It’s unclear if it’s able to bypass auth when FaceID is enabled, but I could see it going either way.)
You said a couple of things that I specifically want to address:
But it doesn’t solve anything that existing TOTP over text messages didn’t solve, other than some complexity, and it eliminated the password (something you know) factor at the server.
and
outside of MitM attacks that TOTP mitigates
Text-message based TOTP - or SMA 2FA - is incredibly vulnerable. In many cases, it can be compromised without the user even realizing. A user with a 4 digit PIN (even if that PIN is 1234) and a Passkey on their device is much less vulnerable than a user using SMS 2FA with a password used across multiple services.
If a user cares deeply about security, they likely already have a set of security keys (like the YubiKey 5C) that support U2F / WebAuthn, and they’ll add passkeys for their most sensitive services to those devices, protected by unique, high entropy PINs. This approach is more secure than using an equally high entropy password and U2F / WebAuthn if the latter isn’t secured with a PIN, since these devices are extremely secure and wipe their contents after 8 failed PIN attempts, but the password is transmitted to the server, which receives it in plaintext and stores it hashed, generally outside of a secure enclave, making the password vulnerable, e.g., if grabbed from server memory, or to a brute force attack on the hash if the server (which could be undetected and only involve read access to the db server), meaning a simple theft of the security key would be all that was needed to compromise the account (vs needing the PIN that is never transmitted anywhere).
And app-based TOTP doesn’t mitigate MITM at all. The only thing it does is add a timing component requirement, which current MITM phishing attacks have incorporated. To mitigate such an attack you need Passkeys, Webauthn, or U2F as an authentication factor. To bypass this the attackers need to compromise the service itself or a certificate authority, which is a much taller task.
The other thing is that we know most users reuse passwords and we know that sites will be compromised, so:
- best case scenario, salted password hashes will be leaked
- likely scenario, password hashes will be leaked,
- and worst case scenario, plain text passwords will be leaked
and as a result, that user’s credentials for a different site will be exposed. For those users, Passkeys are a vast improvement over 1FA, because that vulnerability doesn’t exist.
Another factor is the increased visibility of Passkeys is resulting in more sites supporting them - U2F / Webauthn didn’t have great adoption. And getting these into the hands of more users, without requiring them to buy dedicated security keys, is a huge boost.
For the vast majority of users, passkeys are an improvement in security. For the few for whom they aren’t, those users likely know that, and they still benefit from increased adoption of a MITM immune authentication method, which they can choose on a site-by-site basis. And even they can benefit from increased security by storing passkeys on a security key.
