Encrypting the password hash as alternative to pepper
up vote
2
down vote
favorite
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?
php security hash login passwords
asked Nov 21 at 18:21
IMB
3,957124386
add a comment |
up vote
2
down vote
favorite
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?
php security hash login passwords
asked Nov 21 at 18:21
IMB
3,957124386
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 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 at 18:46
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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?
php security hash login passwords
asked Nov 21 at 18:21
IMB
3,957124386
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?
php security hash login passwords
php security hash login passwords
asked Nov 21 at 18:21
IMB
3,957124386
asked Nov 21 at 18:21
IMB
3,957124386
asked Nov 21 at 18:21
IMB
3,957124386
asked Nov 21 at 18:21
IMB
3,957124386
asked Nov 21 at 18:21
IMB
3,957124386
3,957124386
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 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 at 18:46
add a comment |
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 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 at 18:46
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 at 18:28
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 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 at 18:46
@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 at 18:46
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
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)))
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
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 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 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 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 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 at 12:33
|
show 2 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
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)))
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
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 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 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 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 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 at 12:33
|
show 2 more comments
up vote
1
down vote
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)))
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
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 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 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 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 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 at 12:33
|
show 2 more comments
up vote
1
down vote
up vote
1
down vote
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)))
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
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)))
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
answered Nov 22 at 8:38
martinstoeckli
17.3k43358
17.3k43358
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 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 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 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 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 at 12:33
|
show 2 more comments
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 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 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 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 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 at 12:33
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 at 11:13
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 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 at 11:51
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 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 at 12:09
@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 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 at 12:18
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 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 at 12:33
@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 at 12:33
|
show 2 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418327%2fencrypting-the-password-hash-as-alternative-to-pepper%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 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 at 18:46