Comment by aeternum
5 days ago
>They have to be transmitted.
Everyone knows to hash passwords now and browsers basically enforce SSL. This is not a practical differentiator.
>Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
>If your entire database is stolen, it’s useless.
As are databases containing strong randomly generated password hashes. What is your threat model here, they somehow forgot to hash their passwords yet they are still hashing session tokens, storing customer data in completely separate databases, safely storing private keys, etc.? It requires quite the strawman scenario to apply.
> They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
This is only technically true because of the definition of what a passkey is is vague.
Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.
When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.
So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.
This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.
Can I do hardware attestation across several devices yet? My desktop, my phone, a console, my girlfriends phone of a different brand if I need to log into a shared account, etc?
It seems like one of those things that only works if you're sticking to one ecosystem.
Yes. You can register as many different passkeys as you want. Any limitation in passkeys registration quantity is a limitation of the website/app itself and not a limit of the spec, etc.
3 replies →
>Hardware Attestation solves this problem
Only in theory. Suppose you are a bank, which enclaves/sources/devices do you support vs. not support? What do you do for users on a desktop PC that don't have an enclave? Phishing sites will leverage your weakest enrollment option.
Strictly speaking it's mainly hardware attestation but it's technically "hardware based passkeys" and "remote attestation". So if you rely on attestation in general and don't restrict the attestation source it works just as well.
Software passkeys can be stolen if the client is compromised but they aren't vulnerable to MITM or phishing as long as attestation is used.
> which enclaves/sources/devices do you support vs. not support?
You support all of them and prefer the strongest configuration for the source available.
If you've registered a hardware based key with attestation and then an attack tries to intercept that via phishing or MITM, the key already has its capabilities established and if you try to use the key without attest it should fail.
If you register a key without attestation support then you may be vulnerable to MITM or phishing but you can't intercept a user/their passkey with a stronger set of capabilities and downgrade them.
4 replies →
> (re-enroll attacker's key or register attacker's passkey).
What is the mechanism to do this? As I understand it, the passkey is basically a public/private key pair. You'd have to download the attacker's key pair into your passkey system? What passkey system allows you to provide a key pair, rather than always generating one? I'd like to see a step-by-step walkthrough that doesn't involve a straightforward phishing scenario, or running privileged commands on the users computer (if you can do that, all bets are off.)
>Everyone knows to hash passwords
got a good chuckle out of me. your optimism is inspiring.
Anyone not hashing passwords is going to find a way to mess up passkeys.
How? Public keys are public keys. They are designed for full disclosure. They are "leak proof" in the sense that leaks should not ever matter. The useful thing about public key infrastructure is that it asymmetrically moves the security threat to managing the private key, which is in the user's hands, and away from the public key. With a strong password I have to assume that both my Password Manager is up to the task of not leaking it and that the remote website handles my password correctly (including salting and hashing and not leaking and not using a hash algorithm with known collision flaws and not using a hash algorithm with large well known rainbow tables, etc…). With a passkey I mostly only have to worry that my Password Manager is up to the task, those are the threat models I get to worry about, I no longer have to worry about if a remote website is keeping pace in the ongoing arms race because all they have is a public key that I don't care if it leaks.
3 replies →
> re-enroll attacker's key or register attacker's passkey
Can you walk me through how that would work?
Probably something like this https://cybersecuritynews.com/hackers-abuse-microsoft-entra-...
The article describes a straightforward phishing attack that works specifically against accounts that are _not_ protected by passkeys:
> Depending on which multi factor method the account uses, the victim sees a matching fake screen, whether a one time code prompt, an authenticator app number match, or an SMS page.
The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails. When a phishing campaign with the subject line "Your Mailbox is Full, Log In to Fix Now!" succeeds, that does not demonstrate an interesting vulnerability inherent to your mail server's mailbox size limits.
4 replies →
In this attack, it sounds like the key step was that the user entered their username and password, thinking they were preparing to enter a passkey. It wasn't the passkey system itself (which would prevent this attack), it was the transition from password → passkey system that was attacked.
In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this. This is why every auth system these days is constantly telling you "We'll never ask for X", because at that point, the game is over.
2 replies →
Isn’t that a bug in the Microsoft software, not the pass key specification?
2 replies →