2 ms·

That's possible but it would mean unnecessarily changing security-critical code. I'd again have to make sure to use constant-time comparisons of the different

That's possible but it would mean unnecessarily changing security-critical code. I'd again have to make sure to use constant-time comparisons of the different output, migrate the existing data or require users to reset their passwords and so on. All to tick a box. Ultimately we pretty much did that, switched to scrypt which is based on sha2 and pointed to the standard saying it's sha2-based. But that does not change the fact that the policy imposes incorrect requirements on teams. SHA2 is not appropriate for password hashing.

thaumasiotes 6y ago
> I'd again have to make sure to use constant-time comparisons of the different output Why? What would this mean? You have a flow like this: 1. User sends "password". 2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done. 3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password. But even in step 3, you don't need constant-time comparisons. What purpose would they serve? Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH. But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.
- the8472 6y ago
  Perhaps I was thinking of verifying API tokens. But see, I made a mistake while reasoning about security code. Don't make me do that more often than necessary, one day it'll go wrong.

thaumasiotes 6y ago

> I'd again have to make sure to use constant-time comparisons of the different output Why? What would this mean? You have a flow like this: 1. User sends "password". 2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done. 3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password. But even in step 3, you don't need constant-time comparisons. What purpose would they serve? Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH. But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.

the8472 6y ago
Perhaps I was thinking of verifying API tokens. But see, I made a mistake while reasoning about security code. Don't make me do that more often than necessary, one day it'll go wrong.