Comment on My password is not accepted because it is too long
Redjard@lemmy.dbzer0.com 1 week agoCryptographic hash functions actually have fixed runtime too, to avoid timing-based attacks.
So correct password implementations use the same storage and cpu-time regardless of the password.
Ziglin@lemmy.world 1 week ago
I figured it was about the time spent transmitting. But the password should probably be hashed before sending as well as upon arrival at the server, correct?
Redjard@lemmy.dbzer0.com 1 week ago
It isn’t usually. If it was, the server-side function wouldn’t need a constant runtime at different-length inputs since the inputs would not have differing lengths.
The problem with client-side hashing is that it is very slow (client-side code is javascript (for the forseeable future unless compatibility is sacrificed)), unpredictable (many different browsers with differing feature-sets and bugs), and timing-based attacks could also be performed in the client by say a compromised browser-addon.
For transit a lot of packaging steps will round off transfer-sizes anyhow, you typically generate constant physical activity up to around 1kB. Ethernet MTU sits at ~1500 bytes for example, so a packet of 200 bytes with a 64 char password or a packet of 1400 bytes with a 1024 char password containing some emoji will time exactly identically in your local network.