In Linux we have the salt just next to the password hash in the /etc/shadows file.
I always hear that salt value prevents hashed passwords from being cracked by brute force methods. But if somehow we get the shadow file we can inject the salt in the algorithm and still use a brute force method, right?
I'm not considering the time spent, just the general idea. I know that brute forcing a SHA256 or SHA512 hash will take forever.
Hashing the password with a salt makes it much harder for an attacker to use a precomputed list of hashes (aka rainbow tables) to run the discovered hash against.
It will force him to compute the hashes again for any salted password hash he wants to crack.
Salt doesn't have to be secret. However, it MUST be unique for each password. Consider this : if all your passwords are hashed with the same salt, then an attacker who gets access to your database "only" has to compute H(pwd+salt) for each possible pwd value and he gets all your passwords. If the salt is unique however, the same operation will only get him ONE password, the one associated with the salt he just tried.
A salt does not make brute-forcing a single password any harder, as you correctly pointed out.
Without a salt, an attacker could build one single rainbow-table, and (s)he would get all passwords at once. With a salt, the attacker has to build a rainbow-table for exactly this salt, so he cannot reuse already existing rainbow-tables. When you use a different unique salt for each password, then an attacker would have to build a rainbow-table for each password. This does not make sense, after finding a match there is no advantage to finish this rainbow-table, brute-forcing is cheaper.
With a unique salt per password, one cannot use a precalculated rainbow-table to get several passwords at once.
This also answers the question, why the salt doesn't need to be secret. Algorithms like SHA-* are not appropriate to hash passwords, because they are too fast and therefore can be brute-forced too easily. Use them together with PBKDF2 or use Bcrypt/Scrypt, which offer a cost factor.
You're right. Salting really makes password hacking more difficult for non-trivial passwords, but if some users use common passwords, can still hack the password by brute force a few thousands times.
If the salt is public/stored together, like your case, it is just used to prevent pre-computed password hashes lookup, i.e. rainbow table.
Thus, if for similar algorithms in web applications, I would suggest may also prepend a constant application-specific secret key to the users' password, before hashing by the salted algorithm. Of course if your app secret key is leaked, then this security enhancement is vanished. Thus, I store that secret key in code to separate it from the password hashes database. (That is unachievable in Linux shadow file)
Further remark: the main point of adding the extra "secret key" (or pepper) is: even the hash of a simple password cannot be brute force just few thousand times to crack it (they are as hard as complicated passwords to brute force), given that the hacker only know the password hash, but not yet able to see the secret key in your code. (Meanwhile, it doesn't guard the online website password brute force attempts, it guard the offline attempt to crack the hash itself only)
It makes a dictionary attack a lot more difficult, if the salt is created in a smart way. For example, bcrypt uses a 128 bit salt.
A salt is usually generated randomly. If it was derived only from the password or the password hash, it would indeed not add much security. If it is generated in a way that cannot be predicted by the attacker, it significantly increases the search space - making the brute force attack require a lot more brute force.
Keep in mind that even in a brute force attack, an attacker will still try the predictable passwords (like "pa$$w0rd") first. Assuming an unpredictable 128 bit salt, the attacker now has to try up to 2^128 more possibilities to crack the hash for "pa$$w0rd"+salt. On average that will be half of 2^128 possibilities before the attacker succeeds, which is still 2^127 more possibilities.
