Comment by malfist
5 days ago
> They have to be transmitted.
What do you image happens with passkeys?
> They (or their hash) have to be stored.
What do you image happens with passkeys?
> If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
From the consumer, do you imagine a hacker has my key to unlock my password database?
From a service provider, do you imagine they are not using encryption at rest?
> Cryptography is the solution in passkeys are the implementation.
Do you imagine cryptography is not used with passwords?
The secure part of a passkey does not have to be transmitted. It’s public key cryptography. It’s used to sign something as proof that you control the key.
And for that reason, the server does not have the secret. It only has the public key, which is useless on its own. So it can be stored in the database in plain text unencrypted. And you’re not really taking any risk.
Passwords are not cryptography. People may use cryptography to store them at rest, or their hash. But the true password still has to be transmitted. The first time, and every time.
>But the true password still has to be transmitted. The first time, and every time.
The password never has to be transferred. In fact never having the password should be the goal. Not even a first time. Don't let the password leave their device. You transmit the hash.
That just means the hash is effectively the real password. If an attacker gets a hold of the hash that you transmitted, they can use that to authenticate to the server.
All that you gain by transmitting the hash, is that the attacker will need to modify the client's request to inject the stolen hash.
If the client (website or app) runs on the attacker's own devices, this is trivial. I suppose it is a valid obstacle if we are talking about an ATM or similar locked-down client.
2 replies →