Comment by aeternum
5 days ago
Stealing passwords is already an incredibly rare attack nowadays. The attack is almost always on the cred reset path. Suppose a user loses their phone with the secure enclave and wants to login to your site using their laptop without a secure enclave.
Are you really going to block that cred reset on the grounds that it's a downgrade? You're going to have a lot of users calling your support asking why they can't login after switching devices.
So you allow it, then oops it was not a laptop, it was a phishing site.
?
That's not the argument being made.
The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.
So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.
Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.
Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.
Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.
TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.
The phishing site will say something like "Your passkey is out of date, click here to create a new one" I call that cred reset since it is similar to password reset, perhaps some sites support multiple passkeys, in that case the phishing site will use the register new passkey path instead of reset existing.
Phishing sites already frequently target the reset/create-new-password path because it's actually easier to get a user to generate a new password vs. trick their password manager. Plus 2FA is usually required anyway since no 'remember me' cookie is avail so a password reset is equal in difficulty to a password login.
That method still works just fine with passkeys right?
The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks. Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
> That method still works just fine with passkeys right?
Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.
If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.
> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.
Yep and passkeys explicitly exist to eliminate this behavior.
> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.
Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.
TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.