[mejutoco]

> Sure, but I still think this is preferable to sending the password in clear text even over HTTPS. You're trusting the server doesn't do anything with the password

My point is in both cases the server has access to the password. As I mentioned, without salt the server can get the original password (by checking the pre-computed rainbow table of hashes up to n length), so the trust issue is the same.

If this is slightly better (more obfuscated) or the same thing + a false sense of security is debatable, but I could agree.

[const_cast]

Well no, because rainbow tables are quite small. You don't have precomputed hashes for all passwords 24 characters and under that contain numbers and symbols.

I mean, even with just letters, you're looking at 620448401733239439360000 hashes required. x 128 / 8 bytes, you're looking at ~ 9000 zettabytes. So, a few order of magnitude larger than the entire internet.

If you have a strong password, it's not comparable. In scenario one the server has the password immediately. In scenario two, it would require the heat death of the universe to precompute the hash to find out the password.

[mejutoco]

Very interesting point. I did not think of that, thanks. I was looking at the speed of calculation in different scenarios (calculated on the fly)based on which characters are part of the password and it is still very difficult, if you have a strong password. I am curious which percentage one could match just checking for hashes of common passwords, or common patterns like exclamation marks at the end. In any case it is better than the unhashed version, I agree.

PS Sorry punctuation, mobile phone.