7 ms·

How is this a failure? That's correct. (If your password hashing library doesn't handle this automatically, of course. But it does the same internally.)

• jjawssd 10y ago
  Is it normal for password hashing libraries to save salts to a database?
  • dchest 10y ago
    Yes, they usually produce a string that looks something like "salt||hash". (Salt is a non-secret value.) This result of bcrypt: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy |/ \| \____________________/\_____________________________/ | | salt hash | cost | algorithm, version You store this string in the database.
    • zo1 10y ago
      The big thing about this, is that it is perfectly "OK" to store both the algorithm, cost, and salt alongside the hash. Most people seem to think, and myself included when I was new-to-it, that storing all those things together would compromise the security. The point of the hash is that it is impossible (almost) to get to the hash without the user's password, and there is no way to get to the password with the entire string you posted.
      • DigitalJack 10y ago
        I'm naive about these things, but I was under the impression that salt just thwarted pre-computed hash tables? I guess should be "just" in quotes. So somebody with resources and motive could still brute-force that string. It seems that storing the salt somewhere else would add a comparable amount of security as the salt itself. It seems prudent along the lines of "don't put all your eggs in one basket."
        • CiPHPerCoder 10y ago
          What you're thinking of is called a "pepper" and is discouraged.
        • raverbashing 10y ago
          > but I was under the impression that salt just thwarted pre-computed hash tables? Yes. Because if you had two users with the password 'dadada' they would hash to the same value Now 1234:dadada hashes differently then 1326:dadada hence preventing the use of a prehashed table (you could go through all salts for common passwords, but it's usually a bit long as well)
• CWuestefeld 10y ago
  Rather than expecting the password hash library to store something into your application DB, you should be managing the access to that DB yourself. In our case, we use an immutable attribute of each user as their hash. This might be an internal identifier, or the timestamp on which their account was created, or something like that.
  • dchest 10y ago
    Rather than expecting the password hash library to store something into your application DB, you should be managing the access to that DB yourself. You do manage it yourself. Password hashing library doesn't access your database, it produces a string that you store, which includes salt and password hash. In our case, we use an immutable attribute of each user as their hash What? You really need to talk to security-competent people.
    • deleted 10y ago
      [deleted]
  • peeters 10y ago
    > In our case, we use an immutable attribute of each user as their hash. I assume you mean "as their salt". And even then, why the half-measure? Just laziness? Sure, a guessable/computable salt is better than no salt, but it's not nearly as good as a random salt.
    • CWuestefeld 10y ago
      I assume you mean "as their salt" Yes, thanks for clarifying what I meant to type. why the half-measure? Just laziness? Sure, a guessable/computable salt is better than no salt, but it's not nearly as good as a random salt. But isn't the salt essentially safe to make public anyway? That being the case, how does it matter what value you use, so long as it differs between users?
      • peeters 10y ago