Hacker News Reader

Comment by GoblinSlayer | Hacker News Reader

To prevent hash reuse you can hash the password with a constant per site salt, e.g. bcrypt(sha256("news.ycombinator.com",password))

View on HN

To prevent hash reuse, you can just use a long, cryptographically-random salt. There exist zero reused bcrypt, scrypt, and argon2 hashes globally (assuming “good” implementations that generate salts on users’ behalf).

Yes some implementation consider atomic time apart from thermal noises when generating them.

It's about an attack on prehash described later in the article.

That isn't a salt. Salts are per user, high entropy random strings.

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.

Fair 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.

If you want a complex solution, you can implement SCRAM https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...

um, 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.

A "better" way would be with an hmac sha256.

Reply on news.ycombinator.com