Same salt or Different salt?

Question

I have a super old version of php (please don't tell me to upgrade for it will never be an option in our case) and i need to store passwords. I had seen posts like this and many more that says, use crypt() of php. I am just confuse with one thing:

My question is which is proper way of storing password; Use ONE SAME SALT for all passwords of different users or DIFFERENT RANDOMLY GENERATED SALT for each password of users?

My question arise because in my experience, i haven't seen a database/table with salt in each row, some have a one salt in a config file and it is being used for salting all of the passwords. Also, i think storing different salt in each user simply means more bytes to store.

Thanks guys ♥

possible duplicate of [Secure hash and salt for PHP passwords](http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords) — , Apr 22 '15 at 01:39
How do you know its duplicate? you haven't read my question for you commented exactly 10 secs after i posted this — Ceeee, Apr 22 '15 at 01:40
@Dagon Seriously? you also edited my question? have you read what you are saying a "possible duplicate"? — Ceeee, Apr 22 '15 at 01:44
actually if you look at the time stamps it was 66 seconds, more than enough time. and no i did not edit it — , Apr 22 '15 at 01:45
@Fred-ii- honestly no, even though i pointed him to the greatest resource on the subject, i don't think he love me long time — , Apr 22 '15 at 01:52
@Dagon But im asking a different question 3 and havent found specifically says there that storing different salt for every user is much much better than that having one — Ceeee, Apr 22 '15 at 01:55
everything he liked in the answers below where covered in the question i linked to - im sad now — , Apr 22 '15 at 01:55
Let the function take care of the salting. You may have complications later on. `password_hash()` and `crypt()` has them built into the hash so why complicate things? — Funk Forty Niner, Apr 22 '15 at 01:55
@Ceeee go back to the question search for "Passwords should always be salted before hashed. " there it is in back and white. — , Apr 22 '15 at 01:56
@Fred-ii- Ohh, i had overlooked that, i thought crypt()'s salt parameter is not randomly generated like in password_hash. thanks fred — Ceeee, Apr 22 '15 at 02:07
@Fred-ii- - Sure both functions `password_hash()` and `crypt()` will include the salt in the resulting hash, but it sould be mentioned also that while the password_hash() function generates a safe salt, the crypt() function will _not_. — martinstoeckli, Apr 22 '15 at 09:13

score 3 · Accepted Answer · answered Apr 22 '15 at 01:46

You want to use a different salt. The idea being is that a salt will impact the resulting hash.

When "hacking" passwords that have been exposed, malicious people will use "rainbow tables". These are essentially a reverse look up that finds strings that hash to the given value. Rainbow tables can also be generated for common passwords.

If you use one salt, a hacker will only have to generate one rainbow table. If you use a new salt for each password, the hacker has to generate rainbow tables for each password they wish to compromise.

It is relevant to upgrade your PHP for modern hashing librarys (like bcrypt). However, there are back-ports for older versions of PHP which I seriously recommend. Hashing functions for passwords are designed to be computationally expensive so that a password takes time to verify. The idea being that you cannot verify 1000 different password possibilities in any reasonably short amount of time.

I see, but why is laravel uses the salt defined in application/config/application.php ("application key")? sorry really confused — Ceeee, Apr 22 '15 at 01:48

martinstoeckli · Answer 2 · 2015-04-22T07:57:10.487

Create a unique salt for each password, this is the only safe method. How you can calculate the hash, depends on how old your PHP version actually is:

Version 5.5 of PHP will have built-in support for BCrypt, the functions password_hash() and password_verify(). This function will generate a safe salt on its own and includes it in the resulting hash-value.

For PHP version 5.3.7 and later, there exists a compatibility pack, from the same author that made the password_hash() function. You can then already use the password_hash() function, and should you switch to a newer PHP version you do not have to change your code.

For PHP versions before 5.3.7 there is no support for crypt() with 2y, the unicode safe BCrypt algorithm. One could use the compatibility pack and replace it instead with 2a, which is the best alternative for earlier PHP versions.

For PHP versions before 5.3, there is no support for BCrypt at all. Your best bet will probably be the phpass framework then.

Note that the crypt() function will not create a safe salt on its own, though it will include it in the resulting hash-value. For verification it will extract it from there.

score 0 · Answer 3 · answered Apr 22 '15 at 01:48

Using a single salt for every hash will always prevent a rainbow table attack unless a specially generated rainbow table is generated using the salt you were using, which is astronomically impossible unless your salt is a single character or was known beforehand.

Using the same salt for every hash is also great against hackers that have access to your SQL database but not your back-end code.

However if a hacker has access to your static salt it makes having it almost useless against the speed of a brute-force attack, which having a salt for every user would mitigate.

You should use both a hard-coded static salt and a dynamic salt to both prevent a rainbow table attack and mitigate a brute-force attack.

which means both is super safe but storing different salt for each user is much super safe than the other way? — Ceeee, Apr 22 '15 at 01:53
They both offer different kinds of protection, but using both of them at the same time would be safer than using just either one of them because you would have the benefits of both. — Prime, Apr 22 '15 at 01:56

Same salt or Different salt?

3 Answers3