2

I've a question regarding the suggestion on the 2 top answers on this question.

On the last part of their answers, they're saying it's better to encrypt the password hash than using hardcoded pepper for maintainability (in case your hashes leak, you can rotate the keys).

Is this the pseudo-code of what they're saying?

$key = 'random_key_stored_elsewhere';
$hash = bcrypt($password);
$encrypted = encrypt($hash, $key);
// store $encrypted to DB

Now to check a login attempt:

if (bcrypt($user_input) == decrypt($encrypted, $key))
{
    // proceed login...
}

Say hash leaked, now we need to change the key and re-encrypt the hashes:

$decrypted_data = decrypt($encrypted, $key)
$new_key = 'new_random_key_stored_elsewhere';
$encrypted = encrypt($decrypted_data, $new_key);
// store $encrypted to DB

Is that it? If yes, then how can rotating the keys in case of a hash leak invalidate the would-be cracked passwords if the same procedure is used for checking login attempts? E.g.,

if (bcrypt($user_input) == decrypt($encrypted, $new_key))
{
    // proceed login...
}

Rotating the keys would've been useless right or am I missing something?

IMB
  • 15,163
  • 19
  • 82
  • 140
  • Rotating the encryption key would be done if you feared compromise of the key (or wanted to rotate it every so often for security), not compromise of the hashes themselves. As you correctly surmise, a key rotation wouldn't be useful for that. – ceejayoz Nov 21 '18 at 18:28
  • @ceejayoz I still couldn't wrap my ahead around the idea of rotating keys for this purpose. What's the point of rotating keys everyday if the hacker only needs to crack his copy of the encrypted data anyway (old key) and then he can proceed cracking the user hashes. The original user passwords are the same no matter how many times I rotate the keys. – IMB Nov 21 '18 at 18:46

1 Answers1

1

You are assuming that when the key is lost, the password-hashes are lost as well, which is indeed often the case. In this situation there is no protection, whether you encrypted the password-hashes or used a pepper.

There are other scenarios as well though. Maybe your source code leaked, somebody accidentally checked in the key in the version control system, or a developer machine has a backdoor. As soon as you dicsover such a leak, you can exchange the key on the server, before the database containing the hashes is attacked. With a pepper you had to reset all passwords instead and inform the users about it.

Maybe an attacker got the password-hashes (SQL-injection, backup) and now tries to attack your server to get the key. If you discover it in time, you can exchange the key and the leaked hashes are worthless. You gain the time between the leak of the passwords and the leak of the key to react.

BTW your description is nearly correct, to verify the password you have to decrypt the hash first, then you can verify it with BCrypt (it is not possible to compare it).

if (bcrypt_verify($user_input, decrypt($encrypted, $key)))
martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
  • I get that this is only useful if only the key leaked and not the hashes but why are you still saying this scenario: "Maybe an attacker got the password-hashes (SQL-injection, backup) and now tries to attack your server to get the key. If you discover it in time, you can exchange the key and the leaked hashes are worthless." See this is where I don't get it, if the attacker already have your password hashes, there's nothing you can about it, changing the key doesn't help. – IMB Nov 22 '18 at 11:13
  • The hashes are worthless without the key, because the attacker cannot decrypt the hashes and therefore cannot start brute-forcing. So he can try to get the key from the server (the key is not in the database like the hashes). If you exchanged the key in the meantime, he will find the new key and cannot decrypt the hashes which where encrypted with the old key. – martinstoeckli Nov 22 '18 at 11:51
  • @IMB - Maybe the crucial point is, that the hashes encrypted with the new key cannot be stolen again. So one could e.g. shut down the server until the leaking code is fixed and the hashes are reencrypted. Then the attacker has only old hashes, but the old key to decrypt them doesn't exist anymore. – martinstoeckli Nov 22 '18 at 12:09
  • Ok I kinda get it but at the point if you know your hashes are stolen, the best course of action from there is to NOT ONLY rotate the keys but ALSO invalidate all user passwords (i.e., rehashing all user passwords) so that if the attacker (presumed to have an extreme computing power) manage to crack the key and the hashes they are all useless by then. Would you agree? Now if we only rotate the keys without invalidating the hashes, there still lies the possibility someday this attacker might crack em. – IMB Nov 22 '18 at 12:18
  • @IMB - Rehashing the passwords would not help, and it cannot be done, because you would need the plain text password. Another point is, that a key is not the same as a (weak) user password, it must always be long and random (e.g. 256bit), therefore there is no chance that it can be brute-forced successfully. You are right, that it is the best you can do to contact the users to **change** their passwords, but it is even better when you can tell them, that their old passwords are still protected. – martinstoeckli Nov 22 '18 at 12:33
  • Why would rehashing not help? By rehashing I mean, invalidate/randomize all the passwords so the users will be forced the change it before logging in. I disagree that there is "no chance" a key can be bruteforced because it can still be depending on computing resources, it is not impossible just highly improbable. So I guess the bottom line here is rotate the keys regularly and it case of hashes leak, don't forget to invalidate all the hashes as well. – IMB Nov 22 '18 at 12:51
  • @IMB - This is a very safe approach and most are not willing to go this far, but yes you are right. About the 265bit key, such a key allows for an immense number of possibilities, it is near the number of atoms in the known universe, and since the computers must be built with atoms :-) – martinstoeckli Nov 22 '18 at 12:57