How does salt protect against dictionary attacks?

Possible duplicate:
What is the purpose of salt?

I only read a little about the use of salts, and the example I read makes it possible to add salt to the password before hashing to protect against dictionary attacks.

However, I really don’t see how this helps - if the attacker has access to the password hash (as in the example I read), they will most likely also gain access to the salt. Thus, an attacker cannot add and put salt in each element of the dictionary before starting the dictionary to find out if it matches the hash? Thus, they have to sort through the dictionary many times, which doesn’t seem like strengthening the defense?

+2
source share
6 answers

A dictionary attack is an attack in which an attacker takes a large list of passwords, possibly ordered by probability / probability, and applies an algorithm for each of them, checking the result.

In the case of a salty password, such an attack is still possible (and not significantly more expensive) if the attacker has salt (which is usually assumed): just enter the salt in your algorithm.

What protects the salt is a rainbow table. A rainbow table is a table containing plaintext pairs (e.g. passwords) and corresponding hashes sorted by hash. Such a table allows a simple password search, given the hash.

Creating a rainbow table is an expensive step (depending on the size of the dictionary used as input), but then you can use it at no cost later to find as many passwords as possible.

How salt protects against this, since now you will need a separate table for each salt. Even with a simple 2-letter Unix crypt salt, this is already a 3844 factor. Modern password hashing algorithms use a much larger salt (for example, bcrypt uses a 128-bit salt, which gives a factor of 2 128. )

To protect against dictionary attacks, you will also use the slow hash algorithm instead of the fast, for example, simple MD5 or SHA1 / SHA2. Bcrypt is such an algorithm (with a configurable work coefficient), and the same author later proposed scrypt (which not only takes a lot of time, but also requires a large amount of memory, attackers are often not as much as computing power).

+7
source

1- You cannot use rainbow tables to crack hashes

2- If two users have the same password, the hash will be different if you salt it (so it's harder to catch shared passwords)

+5
source

This increases the work they need to do, increasing the number of possible responses in the password file.

One way to commit a dictionary attack is to scan a password file. If there is no salt, and you see "DFGE $% $%% TEW", then you know that the password is "PASSWORD". Adding salt means that you will either have to use a much larger dictionary containing all the meanings for “PASSWORD” with all possible salts, or you will have to put in the effort to read the salt and make encryption that slows you down. This is no longer a simple search.

Salt also helps in situations where more than one user chooses the same password. Especially in the old days, when the password file was read by all users, this makes it not obvious if the other user has the same password as you, or the same password as you.

+1
source

In fact, salt does not protect against dictionary attacks. It has the following advantages:

  • Increase the computational cost of breaking it, because for each password in the dictator, an attacker needs to try to hash it with all possible salts.
  • Prevention of simultaneous use of the same password by two users. Thus, the attacker must explicitly break all the passwords, even if the same passwords are in the same file (the password hash is always different).
+1
source

Dictionary attacks are based on dictionary words. By adding random salt, you no longer have vocabulary words. Thus, a dictionary-based password hash table will not help crack a password.

0
source

Each salt value requires a different dictionary, so each database that does not use salt can be attacked by the same dictionary.

  • Without salt, an attacker can simply use a ready-made pre-computed dictionary, of which there are many.

  • If you have one salt for your entire database, then they should create a dictionary specific to your database.

  • If each user entry had salt, now they need to create 1 dictionary per user.

0
source

All Articles