Reputation: 7645
Does this look like a safe salt to use with a password? Any improvements or suggestions or obvious flaws?
$salt = '';
for ($i = 0; $i < 50; $i++) {
$salt .= chr(rand(33, 126));
}
Upvotes: 5
Views: 595
Reputation: 108800
I don't think rand
is a good PRNG. If I recall correctly it maps directly to the c PRNG, which in many implementations has a horribly small(like 32bit) internal state.
And it isn't well seeded either. But since the most important role of a salt is preventing pre-calculated rainbow-tables, which this code does, it should be enough.
And I typically split my salt in two parts:
That way an attacker who only gains access to the database but not the config file(a probable scenario if the attack uses SQL injection) then he still can't crack the passwords.
Upvotes: 5
Reputation: 361605
You don't need to make salts really long and it's not important that they be cryptographically secure. The point of salts is simply to make rainbow table attacks harder as you no longer have a 1-to-1 mapping between passwords and hashes. (They also keep administrators with wandering eyes from seeing 482c811da5d5b4bc6d497ffa98491e38 in the database and then knowing Joe's password is "password123".)
Even a 4-byte salt would be more than sufficient as you'd now have 232 ≈ 4 billion potential hashes for any password.
Upvotes: 8
Reputation: 46913
Length is what mostly makes a salt safe. Randomness isn't super important, as long as it is different for every user. You're going to end up storing it in plain-text anyways so you can use it during hashing.
Upvotes: 3
Reputation: 169008
I would use mt_rand
since it is faster, but this is definitely sufficient for salt.
Upvotes: 3