4 ms·
Indeed it is not a salt, but it is not what OP claimed. Instead, I think OP was providing a good solution to the following problem stated in the article about u
by rocqua 6y ago
Indeed it is not a salt, but it is not what OP claimed. Instead, I think OP was providing a good solution to the following problem stated in the article about using a hash to overcome password length limitations:
If an attacker is able to obtain password hashes from two different sources, one of which is storing passwords with bcrypt(sha256($password)) and the other of which is storing them as plain sha256($password), and attacker can use uncracked SHA-256 hashes from the second site as candidate passwords to try and crack the hashes from the first (more secure) site. If passwords are re-used between the two sites, this can effectively allow the attacker to strip off the Bcrypt layer, and to crack the much easier SHA-256 passwords.
OPs solution is neither a salt, nor a pepper. It is however, a nice way to prevent the above problem.
- willcipriano 6y agoFair enough, but adding a database column and generating a random string on registration is perhaps a 10 minute job and provides all those benefits plus many more.
- GoblinSlayer 6y agoIf you want a complex solution, you can implement SCRAM https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
- coding123 6y agoum, no. If using bcrypt, the salt is per user. If the user is using the same password between the two, that's not a weakness of bcrypt for the more secure site. In fact, even if you use bcrypt and 15 peppers on the more secure site, if the password is the same, the password is the same.