Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are salts useless for security if the attacker knows them?

Let's say I have a table of users set up like this:

CREATE TABLE `users` (
    `id` INTEGER PRIMARY KEY,
    `name` TEXT,
    `hashed_password` TEXT,
    `salt` TEXT
)

When a user is created, a randomly-generated salt is produced and stored in the database alongside the results of something like get_hash(salt + plaintext_password).

I'm wondering that if a malicious user gets their hands on this data, would they be able to use it to crack users's passwords? If so, what's a way that it could be prevented?

like image 504
MiffTheFox Avatar asked Jul 08 '09 14:07

MiffTheFox


People also ask

Do salts need to be kept secret?

Hiding a salt is unnecessary. A different salt should be used for every hash. In practice, this is easy to achieve by getting 8 or more bytes from cryptographic quality random number generator. Salt helps to thwart pre-computed dictionary attacks.

What attacks do salts not provide protection against?

"It's important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn't affect how fast an attacker can try a candidate password, given the hash and the salt from your database."

Does salt prevent brute force?

Even with the usage of salt, it does not stop the adversary from attempting a dictionary or brute-force attack against the salted hash.

Does salt increase security?

Using ten different salts increases the security of hashed passwords by increasing the computational power required to generate lookup tables by a factor of ten. If the salt is stored separately from a password, it also makes it challenging for an attacker to reverse engineer a password.


6 Answers

No, they're not useless.

So long as you use a unique salt for each row, then the salt will prevent slow down an attack. The attacker will need to mount a brute force attack, rather than using rainbow tables against the password hashes.

As mentioned in the comments, you should ensure that the salt is a sensible size.

like image 90
LukeH Avatar answered Oct 05 '22 08:10

LukeH


Salting was introduced (or at least made popular) in UNIX /etc/passwd file, which was world-readable. It is usually assumed that the salt as well as the encrypted password is known to the cracker. The purpose of the salt is the slow-down of the cracking process (since the same password won't map to the same encrypted string); it is not a secret in itself.

like image 36
mfx Avatar answered Oct 05 '22 10:10

mfx


Knowing the salt makes it possible to do a brute-force attack, but that doesn't make it useless. Salt prevents the attacker from using an already generated rainbow table (which you could find on the web).

The best way to prevent brute-forcing is simply to use long, complex passwords.

like image 41
Zifre Avatar answered Oct 05 '22 08:10

Zifre


If an attacker knows the salt, the hashed password and the hash algorithm, then they can mount a brute-force dictionary attack (or rainbow attack).

like image 20
Mitch Wheat Avatar answered Oct 05 '22 08:10

Mitch Wheat


This should give you an idea of how it works.

Lets say you want to encrypt a word "secret." After it is encrypted lets say it now looks like this 00110010.

If a hacker knows the encryption algorithm, they can create a table of words and their corresponding encrypted values. So they take the encrypted password "00110010" and find it in the table. Now they know that the password used to generate "00110010" was the word "secret." If you salt the word first, then a generic lookup table will be useless to the hacker. (A generic lookup table being a table of unsalted dictionary words and their encrypted values)

If you salt the word first ("saltsecret"), now the encrypted value will look different, and the hacker wont find it in the lookup table.

However, they can still start creating their own lookup table from scratch using your salt and eventually they will be able to reverse lookup passwords.

So to answer the question, if the passwords are sufficiently complex, it will take ages for the hacker to figure them out. You could change your salt every year and they would have to start creating a table all over again.

like image 37
Kelly Avatar answered Oct 05 '22 10:10

Kelly


No, it's not worthless.

To successfully attack an account, an attacker needs to know the salt for that account (and every account's salt should be different), the hashing algorightm used, and the final stored password hash.

Given all of that information, you can write a program that keeps trying to hash different potential passwords until it finds one that matches.

If it's a bad salt (too simple or short), this can be made much faster because the program can use rainbow lookup tables to match the final stored password hash to the string that was hashed, and then just subtract the salt. But they still need all the information.

If it's a shared salt, this is bad because an attacker and use the salt to generate a rainbow table in advance that's good for any account on your system.

like image 41
Joel Coehoorn Avatar answered Oct 05 '22 08:10

Joel Coehoorn