Missed opportunity for “What the eff is a Passkey?”
That is truly amazing. (Golf clap)
You’re still entering the password or pin for your password manager. I genuinely do not see how this is better. It’s simply an alternative, not an improvement.
-
Password managers are, generally speaking, far more security conscious than the average website. I’d rather send a password to my password manager a couple times a day than send passwords to every website I interact with.
-
One click to confirm vs. 2-3 to autofill. Tiny gains in speed 🤷♀️ If you make a password manager even slightly more convenient than just using
gregspassword123for everything, you can onboard more normies.
Most people that have password managers are already using different passwords for each website. Usually randomly generated. What’s the difference between that and a passkey?
The secret key pair of a passkey is never transmitted over the internet. Even if somebody snoops the authentication, they will not be able to reproduce the secret key to login in the future.
Think of it just like SSH public and private keys.
Normal passwords, are typically provided at login time, and get transmitted, relying on HTTPS to keep them secure, if somebody could observe the authentication, they could reproduce the password later.
(Yes someone could hash the password client side and send over the output… But that’s extra work and not guaranteed)
Client side hashing of a password just makes the hashed result the password, as far as security is concerned.
Unless there is some back-and-forth with the server providing a one-time-use salt or something to make each submission of the password unique and only valid once, at which point that might get snooped as well.
Better off relying on client certificates if you are that concernedPasskey’s approach is actually relatively close to client side certificates. It’s just in a form that is compatible with using a password manager. From the user standpoint once everything supports it properly, logins become relatively transparent and man-in-the-middle is pretty effectively mitigated. The other upside is of course unless you’re hosting your own stuff, no one supports client side certificates. This is an opportunity for all the big players to actually push people into better security.
-
Someone on slashdot correctly pointed out that these are only single factor on the server end. You enter a pin to unlock the device, the server can check if the device says you unlocked it, but there is no sending a second factor to the server. If a device was hacked to get the keys, or just says to the server that you presented a pin but didn’t really, the server has no clue. Passkey + TOTP would be multi factor on the server side.
[This comment has been deleted by an automated system]
This is where PAKE algorithms for secure password checks fits in
TOTP generated on the same device as the passkey is not a secondary factor. It will have been compromised together with the passkey.
For passkeys, the secondary factors are used to access the passkey vault, not auth to the server. And these secondary factors should be a master password, biometrics, or physical keys. TOTP and SMS are out.
I understand how it works, but again, it is not two factors being used to authenticate to the server.
It is a single factor being used to access the vault. The server has no way of confirming this actually happened, the device just tells the server it has happened. A single factor is then used for authentication. This seems especially worth knowing since most cell phones deliberately weaken the security by sharing them between devices.
Passkeys would preferably not be stored on the same device as a secondary factor used for authentication. Hardware tokens have supported them for years at this point, they can also hold TOTP keys instead.
I’m not sure I follow you - if someone can compromise the key material on my phone that is protected by a different factor, then it doesn’t matter whether the 2FA is server-side or not, it’s compromised either way.
If they compromise key material on your phone they still cannot get into whatever you are authenticating to, because it uses a completely separate factor that should not be on your phone.
It seems like you are trying to protect against a compromise of the user’s device. But if their device is compromised then their session is compromised after auth anyway and you aren’t solving much with extra auth factors.
You’re assuming that the passkey is on their phone and the phone is compromised. Passkeys can also be stored in password managers, or hardware tokens, or people’s iCloud or Google accounts. And if someone’s device is compromised, they have keys to everything even if the user never logs into those services to grab session data. If someone compromises my password vault they get passwords, but not TOTP keys. If they compromise my vault that is holding passkeys, that is all they need.
I am only pointing out that a single factor is all that is sent to the sever, with most no longer allowing a secondary factor for authentication, and all of the security is all dependent on the client-side now.
something from a corporation that cannot be trusted?
Except passkeys are an Open Authentication standard from the FIDO alliance. Soooooo, not from a corporation.
https://fidoalliance.org/passkeys/
You can use passkeys in KeePassXC, if I understand correctly.
They are the equivalent of using a hardware key like YubiKey or SoloKey, except the passkey is stored on your phone/PC instead of a USB thumbstick.
still no reason to trust google with this.
they have hijacked and dominated open source software quite a bit in the past.
Except Google was only mentioned in terms of whether or not they support it.
You’re commenting on an article from the Electronic Frontier Foundation, an organization dedicated to fighting for internet and digital freedoms, about an open standard that has only just begun being implemented widely.
Look, I hate corpos as much as anyone, but please let’s please tone down the alarmism.
[This comment has been deleted by an automated system]
