3 ms·

Client hashing limits the variety of hash inputs on the server side, so it is actually worse for security. Think of it this way: hashes of a certain kind follow

Client hashing limits the variety of hash inputs on the server side, so it is actually worse for security. Think of it this way: hashes of a certain kind follow a pattern for which characters are used and the length and they cannot be salted on the client (because then you'd need to send the salt to the client, making it useless) so it is effectively like having a password restriction like that all passwords must be exactly 64 chars long and only use hex chars. Hash once (on the server) and treat passwords as a binary blob (in other words no validation) until they are hashed. Have some sensible upper bound on how big the password blob can be, but make it larger than any reasonable password manager would create (like 100kb).

dusted 5y ago
There are a few flaws in your argument, please don't take this as an insult. Client hashing does not limit the varity of hash inputs on the server side. You should absolutely send salt to the client, even on (especially on) a plaintext connection. There is no law against doing key stretching or using a longer hash on the client. I'm not sure what your reasoning is for sending salt to the client should be useless. Are you arguing somehow that the salt must be private (wrong) and is compromises security in the client ? Think about that for a second, if the client has their traffic sniffed and decrypted, then sending the plaintext password back to the server (your suggested solution) is just as broken. Client side hashing+salting is a compliment to server-side hasing+salting, not a replacement. Simplified: The server stores salt and saltedHashFromPassword ( hash(salt+pass) ) On login request server generates salt' and sends salt and salt'. client sends back hash(salt' + hash(salt+passw)) server compares hash from client to hash(salt' + saltedHashFromPassword) Now, unless you've owned the client, you'll only ever learn their salt, which is not important, and their salt' which changes with each login request.. the resulting hash cannot be played back as the salt' is invalidated after a login attempt. Assuming a secure hashing algorithm, this even works over plaintext connections. As to the 64 chars, true, if you're doing no keystreching (which can be plopped over the example above with no problem), however, I assume you're talking about situations where nobody stole the database (the security implications of clinet side hashing are not relevant in that case), but you mean to "just generate that number between 0 and 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff and send that directly to the server".. Well, nope, because you cannot just do 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff requests as the valid hash changes with each attempt to login, I can't even the maths here, 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff rasied to the 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffth power attempts might still not get you in, the target is moving and there's no guarantee that you will ever hit it.

dusted 5y ago

There are a few flaws in your argument, please don't take this as an insult. Client hashing does not limit the varity of hash inputs on the server side. You should absolutely send salt to the client, even on (especially on) a plaintext connection. There is no law against doing key stretching or using a longer hash on the client. I'm not sure what your reasoning is for sending salt to the client should be useless. Are you arguing somehow that the salt must be private (wrong) and is compromises security in the client ? Think about that for a second, if the client has their traffic sniffed and decrypted, then sending the plaintext password back to the server (your suggested solution) is just as broken. Client side hashing+salting is a compliment to server-side hasing+salting, not a replacement. Simplified: The server stores salt and saltedHashFromPassword ( hash(salt+pass) ) On login request server generates salt' and sends salt and salt'. client sends back hash(salt' + hash(salt+passw)) server compares hash from client to hash(salt' + saltedHashFromPassword) Now, unless you've owned the client, you'll only ever learn their salt, which is not important, and their salt' which changes with each login request.. the resulting hash cannot be played back as the salt' is invalidated after a login attempt. Assuming a secure hashing algorithm, this even works over plaintext connections. As to the 64 chars, true, if you're doing no keystreching (which can be plopped over the example above with no problem), however, I assume you're talking about situations where nobody stole the database (the security implications of clinet side hashing are not relevant in that case), but you mean to "just generate that number between 0 and 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff and send that directly to the server".. Well, nope, because you cannot just do 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff requests as the valid hash changes with each attempt to login, I can't even the maths here, 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff rasied to the 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffth power attempts might still not get you in, the target is moving and there's no guarantee that you will ever hit it.