3 ms·

Wouldn't hashing on the client side possibly introduce a reduction in complexity of the password? The hashed password on the client side could be used in place

by progre 6y ago

Wouldn't hashing on the client side possibly introduce a reduction in complexity of the password? The hashed password on the client side could be used in place of the plaintext password if the channel is insecure. Lets say the password length limit is 256 ascii chars this is 8*256 bits (ok a little less since not all ascii chars are printable), but if hashed on the client (lets be generous and hash to 1024 bits) it's still half the complexity of the plaintext.

ALittleLight 6y ago
I'm not understanding this. Couldn't you choose an arbitrary amount of bits to hash to on the client side?
smolder 6y ago
It's less about bits and more about entropy. Passwords tend to be low on entropy because of words and patterns present in the sequence. Its almost always going to be harder to break passwords by trying every possible hash than doing dictionary attacks against plaintext passwords. 256 bits is around 37 characters of base64 text. Compare that to most passwords and it's safe to say they aren't losing entropy when hashed.
johannes1234321 6y ago
If you are not including humans your maths might be right. With humans not all 8 bits of extended ASCII are realistically used in passwords. And rarely you get passwords longer than 10 characters. And then: By the password not leaving the system you avoid another issue with humans: If the hash is lost (accidental logging and locks leaking and such things happen) this won't allow to sign in to other accounts, where the lazy human used the same password. For machine-to-machine communication tokens with higher entropy can and should be used.
gpm 6y ago
A 128 bit random plaintext is more than secure enough... If you're trying to argue that the user puts in, say, 60 bits of entropy, and that the hashing algorithm is going to accidentally throw out 10 of those to result in 50 bits of entropy, I believe that any hashing algorithm that did that in a way that anyone can exploit with realistic computing power (a computer smaller than the size of the solar system) would be considered irredeemably broken.

by progre 6y ago

ALittleLight 6y ago

I'm not understanding this. Couldn't you choose an arbitrary amount of bits to hash to on the client side?

smolder 6y ago

It's less about bits and more about entropy. Passwords tend to be low on entropy because of words and patterns present in the sequence. Its almost always going to be harder to break passwords by trying every possible hash than doing dictionary attacks against plaintext passwords. 256 bits is around 37 characters of base64 text. Compare that to most passwords and it's safe to say they aren't losing entropy when hashed.

johannes1234321 6y ago

If you are not including humans your maths might be right. With humans not all 8 bits of extended ASCII are realistically used in passwords. And rarely you get passwords longer than 10 characters. And then: By the password not leaving the system you avoid another issue with humans: If the hash is lost (accidental logging and locks leaking and such things happen) this won't allow to sign in to other accounts, where the lazy human used the same password. For machine-to-machine communication tokens with higher entropy can and should be used.

gpm 6y ago

A 128 bit random plaintext is more than secure enough... If you're trying to argue that the user puts in, say, 60 bits of entropy, and that the hashing algorithm is going to accidentally throw out 10 of those to result in 50 bits of entropy, I believe that any hashing algorithm that did that in a way that anyone can exploit with realistic computing power (a computer smaller than the size of the solar system) would be considered irredeemably broken.