Hacker News new | ask | show | jobs
by CWuestefeld 3667 days 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.
2 comments
dchest 3667 days 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.

link
peeters 3667 days 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.

link
CWuestefeld 3667 days 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?

link
dchest 3667 days ago
Ideal salt is a large (e.g. 16 bytes or more) random byte string generated for each password.

If there's a reason for it (in most cases, there is none), some trade offs are possible, e.g.:

Salt is a large random string unique per user, not per password.

Given two hashes of passwords for the same user it reveals whether passwords are the same.

Salt is a small random string or some predictable value.

Attackers can precompute guesses and then look them up.

If you use some immutable identifier per user as salt, both of these attacks are possible. Is there a reason for this? Since you already store password hash in your database, I'm 100% certain that it's not, you can generate large random salt per each password hash and store it.

As for "safe to make public": there are many things in crypto called "public" where "public" doesn't mean that the whole world is free to get it, but instead means an opposite of "private", or, as I like to call them, "non-secret". Yes, salt can be made public, but shouldn't (unless there's a reason for it — like in a kind of client-side crypto where server stores salt and sends it to clients) to avoid precomputation.

link
CWuestefeld 3667 days ago
Salt is a large random string unique per user, not per password.

Of course it's per user.

But "large" makes some sense. My current implementation has maybe 20-22 bits of uniqueness in the salt, certainly less than 16 bytes.

I don't think 16 bytes is necessary even as insurance against the future. Rainbow tables are still expensive to build.

On the other hand, maybe to build just a small table addressing the stupidest passwords ("password","12345678",etc.) it's worth making it more difficult.

link
dchest 3667 days ago
Of course it's per user.

What I meant is that it shouldn't be per user, it should be per password. If a user changes his password, he should get a new salt.

link
CiPHPerCoder 3667 days ago
> I don't think 16 bytes is necessary even as insurance against the future.

The birthday problem comes into play here.

If you have 22 bits of entropy in your salt, after 2048 users (2^11) you will find two with the same salt, with 50% probability. If they also use the same password, this makes attacking your users much easier.

Don't make it easy for attackers. Use 16 bytes from a CSPRNG. Better yet: Use a password hashing library that takes care of this for you.

If you use a 128-bit (16-byte) salt, you have a 50% chance of a collision after 2^64 passwords.

link
peeters 3667 days ago
It being unique goes most of the way, you're right (though hopefully it actually is unique!). I was being dramatic when I said "not nearly as good". But making the salt easily guessable does allow an attacker to precompute rainbow tables, etc. So if there was a breach and an attacker got a dump of your password hashes, it might mean the difference between you having time to invalidate those passwords or not.

Good look at the issue here: http://security.stackexchange.com/questions/41617/do-salts-h...

link