Static Salt vs Random Salt - PHP Security

Question

Is there any difference between

$hash=sha1($key.$staticSalt); 

and

 $hash=sha1($key.$randomSalt); 

If I use a random salt, I need to store a random salt in the database, on the other hand, if I use a fixed salt, then there is no need to use a DB!
And if the code can be cracked to see the salt (static), then the hacker will be able to see the database also with a hash and a random salt: D
Is it worth it? What if I use salt like @#kiss~89+.&&^me ?

Answer 1

Random salts have huge benefits. If all accounts in the system use the same salt, an attacker can trick the hashes for this salt and break all accounts with only one computational run. If they use different salts on one account, brute force leads you to only one account.

Answer 2

While best practice for storing passwords requires that they be stored in a hashed format with a unique salt, the original question actually raises a pretty good point: if you store the salt elsewhere for hashes, the effect of these hashes that are expanded is omitted .

1) If the passwords were only hashed and stored in the database, and the site was subjected to SQL Injection, then the attacker can “crack” the hashes

2) If the passwords were hashed with salt, and both the hashes and the salts were in the database, and the site had SQL Injection, then the attacker could “crack” the hashes, but would require more computational effort (since there doesn’t increase the performance of the previously calculated tables)

3) If the passwords were hashes with salt, and the salt was stored somewhere else, then SQL Injection will provide an attacker with a little leverage to establish the actual password.

Scenario 1 is obviously the weakest, but the security difference between 2 and 3 is less clear and depends on the relative probabilities of SQL Injection versus server-side code disclosure (and related vulnerability classes).

The more you trust, your ability to protect against SQL Injection or your ability to Apache / PHP / to protect your server-side content.

Things are never simple, and I actually think the idea in OP makes more sense than other answers give honor.

(You can use both the salt stored in the database and the "key" if you like to store it in the source of the web application when generating passwords).

Answer 3

Salt is random by definition; there is no such thing as "static salt". If this is not an accident, this is not salt, but the key.

The salt point is to make sure that the attacker must set up a separate attack for each password that he / she wants to crack. In other words, the hash sucking point is to prevent precalculations ( rainbow tables ).

A simple solution for proper operation is to use a standard library instead of reducing corners

Answer 4

Always use a random salt for each password.

If you do not, the advantage is that salt is lost. If you use the same salt, if a website is hacked, a hacker can use the same hash table to crack all the passwords in your user list. If the salt is random, then it should have a new hash table for each user.

Answer 5

I'm not sure if you are salty. The purpose of salt is to disrupt previously attacked dictionary attacks if your database is compromised. So you use the database to start, so what does the comment “no need to use a database” mean?

If you do not use random salt, it will not be harder for you to attack the attacking your hashes if they get their hand from the salt. You will be better off using a random salt - you will not need to hide it for security.

Salt should also not be long or unusual. "RK" is good salt. "1q" is good too. Its purpose is simply to change the output of the hash function.