[t3nary]

Hashing with an insecure algorithm and without good salting isn't much better that not hashing at all though.

[dchest]

Nope, it is much better for those who use passwords with good entropy.

[dzhiurgis]

How do you store salt?

[CiPHPerCoder]

That question should never even need to be asked. The library you're using should take care of that for you.

In PHP:

    $storeMe = password_hash($plaintext, PASSWORD_DEFAULT);
    if (password_verify($plaintext, $storeMe)) {
        // Logged in
    }

The detail is totally abstracted away. All sane password hashing libraries offer this API.

See: https://paragonie.com/blog/2016/02/how-safely-store-password...

EDIT - CANNOT REPLY:

  > One major failure of this article:
  >
  > You should generate a random salt for each user and store it alongside the user
  > record in the DB.

No, you shouldn't. Your library should do that for you, and store it as a single string that's opaque to the developer.

  > I completely disagree. This implies that my DB ORM handles password stuff,
  > which doesn't make sense.

See the passlib section: https://paragonie.com/blog/2016/02/how-safely-store-password...

[jjawssd]

One major failure of this article:

You should generate a random salt for each user and store it alongside the user record in the DB.

[dchest]

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]

Is it normal for password hashing libraries to save salts to a database?

[dchest]

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.

[CWuestefeld]

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]

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.

[peeters]

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

[tamana]

But then you are using php so you already lost.

[CiPHPerCoder]

If there was any truth at all in that claim, you should be able to compromise paragonie.com right now simply for it running PHP.

Otherwise, that claim is false.

[jjawssd]

> No, you shouldn't. Your library should do that for you, and store it as a single string that's opaque to the developer.

I completely disagree. This implies that my DB ORM handles password stuff, which doesn't make sense.

Python 3 example:

Syntax: hashlib.pbkdf2_hmac(hash_name, password, salt, iterations, dklen=None)

Example:

>>> dk = hashlib.pbkdf2_hmac('sha256', b'password', b'salt', 100000)

>>> binascii.hexlify(dk)

b'0394a2ede332c9a13eb82e9b24631604c31df978b4e2f0fbd2c549944f9d79a5'

Extremely simple and safe to use. Trivial to store and save/retrieve the salt from DB.

[peeters]

I'm not too familiar with this library, but on inspection this approach seems to have a couple of drawbacks that libraries like bcrypt solve for you:

1) You need to store the salt alongside the password.

2) If you want to futureproof the stretching factor (e.g. change from 100000 to 1000000), you need to store that alongside the password hash as well.

3) If you want to futureproof the hashing algorithm, you need to store that alongside the password hash.

The value of the *crypt solutions is that they store the input parameters as part of the stored secret. So you can make adjustments later on without invalidating existing stored passwords, or having to resort to annoying "double-hashes" to migrate to a new approach.

I don't understand your comment about the ORM needing to handle passwords. It's a simple fetch of a field from the DB, which you then pass as an input to your password validator. How is that any harder than fetching a salt and a hash and passing those to your validator?

[jjawssd]

I did not realize that the hash and salt are concatenated