3 ms·
If you hash the password on the client, the hash made on the client is now the password. It's easy enough to send the hash directly, and the server is none the
by LyndsySimon 9y ago
If you hash the password on the client, the hash made on the client is now the password. It's easy enough to send the hash directly, and the server is none the wiser.
That's not to say it's a bad idea, though. I have used client-side hashing in the past to allow passwords of arbitrary length while using finite network resources.
- gsich 9y agoTrue, but at least no sensitive information is available on the server side. People do reuse passwords.
- John_KZ 9y agoThat's not true if you ask the client to hash both the password and a one-time token you just send. Knowing both the password/key (which was send during registration) and the token, you can calculate the hash. Otherwise you can't. Password/key is never transmitted. You can also use asymmetric encryption. I always cringe with amateur devs sending plaintext.
- yorwba 9y agoYour scheme requires the server to store the password in plaintext, and it's transmitted at least during registration.
- John_KZ 9y agoIt does. You can do the same with with the salted hash of the password and not the password the user entered. It's still worse than real authentication protocols where you don't store the shared secret at all, but better than those diy schemes described earlier. Also you can't get away from sending the shared secret during registration. Even with asymmetric cryptography you have to rely on the TLS to make sure you exchange the real untampered public keys.