Are Salt strings stored by application? [duplicate]

Question

1) As storing passwords in plain text in databases are not secure and so is not a good practice.
password stored in db = "abcde" (plain text)
2) To avoid this, passwords are stored after being hashed using some reliable hashing techniques like SHA256 or SHA 512 etc.
password stored in db = SHA256("abcde") = 36bbe50ed96841d10443bcb670d6554f0a34b761be67ec9c4a8ad2c0c44ca42c
3) But since hashed passwords are vulnerable to rainbow table attacks or dictionary attacks, a new technique of salting is applied. Here a salt (some string) is added(normally prefixed or suffixed) to password and then the resulting password+salt is hashed and stored in db.
password + salt = "abcde" + "catsarecool" and
password stored in db = SHA256("abcdecatsarecool") = 8A85335AB6B09405FF34DCC146A0B690A3BFA834B8C53EBAD77F64C653A89F82

Now I can explain/ask about what I want to confirm and the worries I have -
1) when using salting(3), i would guess that the salt string should also be stored in the DB. Please confirm?
2) If the salt string has to be stored in DB, what's the best practice - using a common salt for all users of application or one salt per user.
3) a) The whole purpose of hashing was that any attacker obtaining the DB dump will be able to see the passwords in plain text which is less secure than when hashed.
b) And the purpose of salting is to make this job more difficult by making dictionary or rainbow table attacks impossible as the attacker will also have to make a guess for "salt" along with password. But if a attacker is able to obtain DB dump somehow, then the attacker would have the "salts" also which, if stored in db, are stored as plain text. So now that the attacker knows the "salt", is not his job of cracking the password just as difficult as it was when he was trying to crack hashed passwords.

I am not a security expert but I am aware that for storing passwords, slower techniques like bcrypt or scrypt or PBKDF2 will be more appropriate. Comments on these or other techniques which are best for storing passwords are welcome. But I am concerned about above scenario for learning purpose? So kindly share your thoughts.

Answer 1

You've got multiple questions in one so I will answer what I believe is your main question.

Use one salt per password per user. This stops rainbow table attacks as an attacker now needs a rainbow table for every possible password with every salt you are using. For them to compute this would be infeasible. I would recommend using PBDKF#2 or bcrypt or one of the other password based key derivation functions (PBKDF). In this day and age hashing, even with salt, is now seen as a weaker solution than using a good PBKDF.

Answer 2

The purpose of a salt is to prevent the use of a rainbow table. Hackers often have quit large files that contain precomputed hashed, they use this to speed up password cracking.

By adding a salt to your password, you're essentially turning "password" into "passwordGSVKELWO". Preventing the use of a rainbow table, and further increasing the complexity of bruteforcing the password. However in order for you to verify the hash you need to know the salt you used to create it. As such, it's accepted that you store the salt alongside the password hash, and use it to check a users password when they login. Now because you're keeping track of the salt, you should definitely go ahead and use unique ones for each user.

Algorithms like bcrypt have a parameter called work, which dictates how CPU intensive it is. A high work value may add one or two seconds to login, but when an attacker tries to crack it will become exponentially slower.

Using these techniques is acceptable for learning, but not development. Use a widely known and accepted library to handle your password hashing and checking, to ensure you're protected against all avenues of attack.

Answer 3

Ok lots of questions, here we go.

1) Yes the salt has to be stored in the database. Otherwise it will not be possible to verify the hash. Typically the salt as a byte array is appended or prepended to the hash and then base 64 encoded and stored as a string.

2) Yes, one salt per user is the norm, stored as above.

3) a) Yes absolutely that. b) It is still somewhat harder. A unique per user salt means that two users with the same password have different hashes. With a fixed salt they will be the same. This means that the hashes can be broken by some sort of frequency analysis.

Current best practice is not to use a single hash using something like sha256 as the algorithm is fast and that makes it faster to brute force. Typically that is accomplished by performing many rounds (perhaps 10000) of hashing or some other method of tuning the amount of work required. As a user you can wait a second for the hash to be verified when logging in. As a attacker it massively increases the time taken