1

Please help me with my understanding. Also I am not talking about SSL or DH key exchange. As the salt is stored in DB and is a secret to the attacker to just protect the user original password (Rainbow tables), in case attacker gets their hand on the actual DB itself. Then how will how you protect against brute/dictionary based attacks. Once again, logging the wrong requests and denying IP of many bad request is known, I am talking about cryptography here. As the password is same for user1, attacker got it from other websites, how does salt protects here. I guess not, then what are the best solutions available to stop such attacks. Assume data is really important like credit card numbers + CVV(I know don't store CVV, but that is not the question).

EDIT: By the way, I came up with some stupid idea, and it looks like a known method for stopping dictionary attacks. Read more this question: High cost encryption but less cost decryption

May be we can discuss some other methods here, to protect against brute/dictionary/social engineering password attack

Community
  • 1
  • 1
Priyank Bolia
  • 14,077
  • 14
  • 61
  • 82
  • 4
    my opinion, fwiw: if you're storing only the salted password, and you protect the server to the best of your ability, you've done your part. the user has some responsibility to choose a password that isn't easily susceptible to a dictionary attack. – jcomeau_ictx Mar 19 '12 at 07:45
  • Agree with jcomeau_ictx, but still without sending salt to user, what can be done to make dictionary attacks more hard. – Priyank Bolia Mar 19 '12 at 07:50

4 Answers4

3

It's a little unclear to me what your actual question is, but if it is "How does a salt help protect me against brute force attacks?" the answer is that technically it does not. There is nothing about a salt that makes brute force attacks more difficult, salts instead make it difficult to brute force multiple accounts simultaneously. Essentially salts artificially inflate search space required to do a brute force attack, making it computationally difficult to pre-calculate every possible password and then check them against the entire database. Salts can be stored in the clear, so long as they are unique to each password.

If you want to make brute forcing passwords more difficult, what you want is an adaptive hashing scheme. These schemes allow you to dictate how long hashing should take. Because an honest client should only have to authenticate on the order of tens of times, but an attacker will need to do it on the order of millions or billions of times, slower hashes make the task near impossible for the attacker while introducing little overhead in the system.

What this all boils down to is that you should use bcrypt if you are hashing passwords. It is designed to incorporate a salt and is an adaptive hashing system. For more info, see this article on security.stackexchange.com

Community
  • 1
  • 1
TwentyMiles
  • 4,063
  • 3
  • 30
  • 37
2

About salt : If you search the "MD5" encrypted password using search engine like google, here you may find the original plain password. But if you mix the salt in your plain password and then apply "MD5" encryption, you wont be able to find it. If any hacker anyhow hacks your database and if you are using just MD5 encryption then he may use above method to hack passwords. For e.g. Search this string on google : 5f4dcc3b5aa765d61d8327deb882cf99, you'll get original password string. Salt is mainly added to protect against such attacks.

Check out here. Look at Just content and concept here to understand. This is from Spring security docs.

Nandkumar Tekale
  • 16,024
  • 8
  • 58
  • 85
  • agree, but then how to stop dictionary attacks, when we are not sending salt to the user. – Priyank Bolia Mar 19 '12 at 07:48
  • the question is different, your answer is about use of salt, which is already known. The question is salt is itself hidden in DB, then how to force user to send different data each time for validation. – Priyank Bolia Mar 19 '12 at 07:55
  • salt can be username, It depends on you what salt to use. if you use salt username, username and plain passwords are mixed, and then MD5 encryption is done. This is the use of salt. And salt is used to avoid Dictionary attacks. Read on link mentioned in answer. It is given there. – Nandkumar Tekale Mar 19 '12 at 08:18
  • There is no point of making username as salt (many posts on SO), username is known stuff and not random for that user. I don't remember, but yahoo used to send a random salt on login years back, I want the same way, but my issue is I am not storing the password, I am storing a salted hash. – Priyank Bolia Mar 19 '12 at 08:55
1

The purpose of a salt is not to prevent dictionary attacks; it is to prevent precomputation attacks such as rainbow tables. Having a salt requires the attacker to attack each password individually, after they gain access to the database; they can't precompute hashes for passwords in the dictionary, or reuse this effort across users.

Password Stretching is a way to make dictionary attacks more difficult, by increasing the amount of work the attacker has to do to test each candidate password.

Nick Johnson
  • 100,655
  • 16
  • 128
  • 198
  • that's what I understand. My question is I know some sites send a random salt/token to be hashed with the password and to be send back to the server for authentication. How does that work, if you don't want to store the actual password itself on server. – Priyank Bolia Mar 20 '12 at 13:15
  • @PriyankBolia You're going to need to be more specific - and this sounds like a different question than the one you're asking, so you should post it separately. – Nick Johnson Mar 21 '12 at 06:42
0

Without salt, an attacker can use an offline attack to precalculate the hash of common passwords: "secret" "qwerty" etc. No salt allows an attacker to tell when different users are using the same password, as they will have the same hashes. Salt prevents precalculation and avoids the matching hash problem.

An attacker with access to the datbase will also have access to the salts. She will need to attack each password separately, because of the different salts.

Using stretching (repeated hashing) can also slow down an attacker. Rather than storing hash(password + salt) you store hash^n(password + salt), where n is large enough for the overall calculation to take at least 0.1 second . That limits the attacker to around ten trials a second while having no discernible impact on the user.

rossum
  • 15,344
  • 1
  • 24
  • 38
  • Sorry but again wrong answer, this is already known. Please read the other answers and my comments. I am interested in how and if salt provides any benefits in dictionary based attacks. Attacker here is not generating password from rainbow tables, he might be using some dictionary attacks. Some sites I think send a salt to the user to be hash along with the passwords and send the hash for verification. I want to know how that works, if the site is not storing the password itself in the first place, but hash of the password. – Priyank Bolia Mar 19 '12 at 16:47