Related
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
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
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.
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.
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.
From this site http://codahale.com/how-to-safely-store-a-password/:
It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks.
If salt is useless to prevent dictionary attack, why using salt?
For single passwords, it doesn't make that much of a difference. Brute-forcing an unsalted password is just as hard as brute-forcing a salted password. You just try out keys until you get a hit.
The difference is when there are a lot of passwords, for example in a leaked database. The basic idea is that part of the necessary computations can be re-used when cracking many passwords. This is done by constructing a rainbow table. Doing that is computationally expensive, but once done it allows the attacker to crack a lot of passwords relatively fast. Cracking N passwords with a rainbow table is a lot faster than brute-forcing those N passwords individually.
If every password is hashed with an individual salt, you can't re-use information in the same way. You could still construct rainbow tables, but they would only be usable for exactly one password in the database, which renders them useless. So in order to crack N passwords, you really have to brute-force all N passwords individually, which is usually not practical for the attacker.
For unsalted passwords and popular hash algorithms, you can simply download pre-calculated rainbow tables from the Internet, so an attacker wouldn't even have to calculate them by himself. He can just download a table and lookup the password for a particular hash. A salt prevents that.
Unsalted hashes also have the drawback that the password hash for two users with the same password is identical. So if an attacker finds multiple users with the same password hash, he only has to crack that password once.
If the 'attacker' has the password hash (and salt) used by your site/app they will simply brute force "salt" + "password".
However, using a salt offers more protection against rainbow tables (precalculated hash tables) so they're still worth using.
Salts prevent instant cracking from a dictionary via rainbow tables; the article and follow-up make the point that the CPU/Storage tradeoff is now such that rainbow tables don't make sense, and so salts don't help you. And of course, they never helped with brute-force attacks.
For illustration purposes, say you are using 2 character string for salts which can be a random element from the set
salts = {'00', '01', '02'...... '99'}
The formula you use is:
salt = salts[rnd(100)] # gets a random element from the set above, say '87'
password_hash = MD5(password + salt) # say the hash is 'dai480hgld0'
Thereafter you'll save the hash and salt in your database, something like
+---------------------------+
| password_hash | salt|
+---------------------------+
| dai480hgld0 | 87 |
| sjknigu2948 | 23 |
| . | . |
| . | . |
+--------------------+------+
We assume that in a compromised system an attacker has access to your code - so he knows how you calculated your hashes.
The attacker will also have access to your database, so he has all the password hashes and the salts.
Given this information, in order to do to crack your password (which has a hash: 'dai480hgld0') he'll have to do the following:
for word in dictionary_words #iterate over all the words in dictionary
for salt in salts #iterate over all possible salts (100 iterations)
password_hash = MD5(word + salt)
if password_hash == 'dai480hgld0'
print "The password is " + word
exit()
endif
next
next
Note that if you'd have not used any salt at all, the algorithm would have been
for word in dictionary_words #iterate over all the words in dictionary
password_hash = MD5(word)
if password_hash == 'dai480hgld0'
print "The password is " + word
exit()
endif
next
From the above two code samples, its obvious that adding a salt to the password increases the number of attempts in the brute force attack. In our case since there are 100 possible salts, you've made the attacker try each word with 100 salts.
So, to conclude:
Salts are good. They make your passwords tough to crack. Even if your users enter weak passwords, the salt makes sure that the resultant hashes are not googlable. For eg, its easy to google a hash '3cc31cd246149aec68079241e71e98f6' which is actually a password that is fairly complex and will meet almost all password policies. Still cracking it requires not a single line of code !
Salts are not panacea. They just increase the time it takes for a cracker to brute force your passwords. However, if your salt address space is fairly big then you are pretty good. For eg, if you have 32 characters alphanumeric string as a salt - brute force will really take very long.
Slow algorithms like bcrypt help you in this regard just because they are well... 'slow'. For a brute force attack, it will take unrealistically long to break hashes that are slow to compute.
Salt makes the encryption stronger. However, dictionary attacks don't try to decrypt the password hash, so salt or no salt, it doesn't matter, they will just try out many passwords until one works.
Now this doesn't seem like a programming question, so I'll just give you some info on salting and encryption:
The purpose of salting is to aid in one-way functions like Hashing, which is used widely in Cryptography, often in use of passwords because of its difficulty to guess, and time it takes for other attacks like brute-force attacks to crack them.
If you want to securely store passwords, the best way is definitely encryption. Look up encryption on Wikipedia for more info on that.
It is not entirely accurate, as with most things it depends on your assumption.
main assumption are:
Attacker has salt
calculation of hashes "on the fly" are done pretty quick (as with salt he will need to recalculate all and wont be able to use predefined lists)
same salt for each user.
Two comments:
Regular hash algorithms can be iterated. There is no need to use a non-standard algorithm just because you want to increase the work factor.
Using a Salt is to be recommended even if you use a slow hash method. It might not necessarily increase the work load of the best attack, but it will stop trivial attacks in case a user chooses a password identical to that of another user, another account or to an old password.
This belongs on security.stackexchange.com
The problem is one of compute capacity in combination with the speed of the hashing algorithm. Basically, he's pitching bcrypt which is slow.
If a hacker has both the hash and salt used as well as knows the algorithm used to hash the password, then it's simply a matter of time to crack it.
If using a very fast algorithm, then that time is pretty short. If using an extremely slow algorithm then the time is, obviously, much longer to find a hit.
Which brings us to the primary reason why we hash/salt things in the first place: to buy time. Time that can be used in order to change all of the passwords listed and time to contact all of the users to let them know in case they need to change their passwords on other systems.
The reason we use salt is to force the hacker to build a rainbow table per salt value. This way one table can't be used to crack all of your passwords. The only reasons to do this are to buy time and, hopefully, dissuade the common hackers from investing further resources in cracking all of them.
Hashed passwords, regardless of mechanism used, are not secure in the sense that most people take that word. Secure doesn't mean "can never be cracked". Rather it means "this is going to be expensive in term of time/effort to crack". For most hackers, they want low hanging fruit such as clear text only. For some, they'll go to whatever extreme is required, such as building massive rainbow tables per salt value to get them all.
And, of course, underpinning this is whether any "super" user accounts are easily identified in your user table. For most systems just cracking the sys admin type of account is good enough and therefore the fact of using a different salt value per user is immaterial. The smart ones will just bother with that one account.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the purpose of salt?
I've just been reading up a bit about the use of salts, and the example I've been reading gives that of adding a salt to a password before hashing to protect against a dictionary attack.
However I don't really see how that helps - if the attacker has access to the hash of the password (as they do in the example I've been reading) they most likely they will also have access to the salt.
Therefore can't an attacker just prepend and postpend the salt to each item in a dictionary before running through the dictionary to see if it matches the hash? So they have to iterate through the dictionary more than once, that's doesn't seem much of a protection enhancement?
A dictionary attack is an attack where the attacker takes a large list of passwords, possibly ordered by likelyhood/probability, and applies the algorithm for each of it, checking the result.
In case of a salted password, such an attack is still possible (and not significantly costlier), if the attacker has the salt (what is normally assumed): Simply input the salt in your algorithm, too.
What a salt protect against, is a rainbow table. A rainbow table is a table containing pairs of plaintext (e.g. passwords) and the corresponding hashes, ordered by hash. Such a table allows a simple lookup of the password, given the hash.
Producing a rainbow table is a costly step (depending on the size of the dictionary used as input), but then you can use it without any cost later to lookup as many passwords as wanted.
As salt protects against this, since you now would need a separate table for each salt. Even with the simple Unix crypt's 2-letter salt, this already is a factor of 3,844. Modern password hash algorithms use a much larger salt (for example bcrypt uses a 128-bit salt, which gives a factor of 2128.)
To protect against dictionary attacks, too, you'll use a slow hash algorithm instead of a fast one like simple MD5 or SHA1/SHA2. Bcrypt is such an algorithm (with a configurable work factor), and the same author later proposed scrypt (which not only takes much time, but also needs lots of memory, which attackers often don't have as much as processing power).
1- You can't use rainbow tables to crack the hashes
2- If two users have the same password the hash would be different if salted (so it's harder to catch common passwords)
It does increase the work they have to do by increasing the amount of possible answers in the password file.
One means of doing a dictionary attack is to scan the password file. If there is no salt and you see "DFGE$%$%£TEW" then you know the password is "PASSWORD". Adding salt means you'll have to use either a much larger dictionary containing all the values for "PASSWORD" with all possible salts, or you have to spend the effort to read the salt and do the encryption which slows you down. It's 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 readable by all users, it makes it not obvious if another user has the same password as you, or the same password as one you know.
Actually a salt doesn't protect against dictionary attack. It has the following benefits:
Increase the computational cost of breaking it, because for each password in the dictonary the attacker need to try hash it with all possible salts.
Prevent two users that have the same password to have also the same hash. This way an attacker has to explicitely break all the passwords even if there are identical passwords in the same file (the hash of password is always different).
Dictionary attacks are based on words from the dictionary. By adding a random salt, you no longer have dictionary words. Thus a password hash table based on dictionary words will not be helpful in cracking a password.
Each salt value requires a different dictionary, so every database that doesn't use a salt can be attacked with the same dictionary.
Without any salt an attacker can just use an off-the-shelf
pre-computed dictionary, of which there are plenty.
If you have one salt for your entire database then they need to
create a dictionary specific to your database.
If each user record had it's own salt, now they need to create 1
dictionary per user.
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?
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.
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.
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.
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).
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.
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.
Assuming brute force attack of MD5,SHA1,SHA256 algorithms with GPU has a throughput greater than 1 billion of tries per second and SHA512 around 300M/s. If you use one of these algorithms, it will slow down hacker who used rainbow table (less likely), but it will not slow down hacker who used brute force attack (more likely). It will definitively not protect you, it just add a bit of security against outdated rainbow table (for these algo). A bit is better than nothing.
But if you use a strongest algorithm (eg. bcrypt), salt definitively worth it even if stored with hash because brut force is not feasible in term of time so rainbow make sense.
Have a look at this
article and to summarize:
If you are a user:
Make sure all your passwords are 12 characters or more, ideally a lot more. I recommend adopting pass phrases, which are not only a lot easier to remember than passwords (if not type) but also ridiculously secure against brute forcing purely due to their length.
If you are a developer:
Use bcrypt or PBKDF2 exclusively to hash anything you need to be secure. These new hashes were specifically designed to be difficult to implement on GPUs. Do not use any other form of hash. Almost every other popular hashing scheme is vulnerable to brute forcing by arrays of commodity GPUs, which only get faster and more parallel and easier to program for every year.
Posted by Jeff Atwood
At work we have two competing theories for salts. The products I work on use something like a user name or phone number to salt the hash. Essentially something that is different for each user but is readily available to us. The other product randomly generates a salt for each user and changes each time the user changes the password. The salt is then encrypted in the database.
My question is if the second approach is really necessary? I can understand from a purely theoretical perspective that it is more secure than the first approach, but what about from a practicality point of view. Right now to authenticate a user, the salt must be unencrypted and applied to the login information.
After thinking about it, I just don't see a real security gain from this approach. Changing the salt from account to account, still makes it extremely difficult for someone to attempt to brute force the hashing algorithm even if the attacker was aware of how to quickly determine what it was for each account. This is going on the assumption that the passwords are sufficiently strong. (Obviously finding the correct hash for a set of passwords where they are all two digits is significantly easier than finding the correct hash of passwords which are 8 digits). Am I incorrect in my logic, or is there something that I am missing?
EDIT: Okay so here's the reason why I think it's really moot to encrypt the salt. (lemme know if I'm on the right track).
For the following explanation, we'll assume that the passwords are always 8 characters and the salt is 5 and all passwords are comprised of lowercase letters (it just makes the math easier).
Having a different salt for each entry means that I can't use the same rainbow table (actually technically I could if I had one of sufficient size, but let's ignore that for the moment). This is the real key to the salt from what I understand, because to crack every account I have to reinvent the wheel so to speak for each one. Now if I know how to apply the correct salt to a password to generate the hash, I'd do it because a salt really just extends the length/complexity of the hashed phrase. So I would be cutting the number of possible combinations I would need to generate to "know" I have the password + salt from 13^26 to 8^26 because I know what the salt is. Now that makes it easier, but still really hard.
So onto encrypting the salt. If I know the salt is encrypted, I wouldn't try and decrypt (assuming I know it has a sufficient level of encryption) it first. I would ignore it. Instead of trying to figure out how to decrypt it, going back to the previous example I would just generate a larger rainbow table containing all keys for the 13^26. Not knowing the salt would definitely slow me down, but I don't think it would add the monumental task of trying to crack the salt encryption first. That's why I don't think it's worth it. Thoughts?
Here is a link describing how long passwords will hold up under a brute force attack:
http://www.lockdown.co.uk/?pg=combi
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.
From a previous answer of mine:
Salt helps to thwart pre-computed dictionary attacks.
Suppose an attacker has a list of likely passwords. He can hash each
and compare it to the hash of his victim's password, and see if it
matches. If the list is large, this could take a long time. He doesn't
want spend that much time on his next target, so he records the result
in a "dictionary" where a hash points to its corresponding input. If
the list of passwords is very, very long, he can use techniques like a
Rainbow Table to save some space.
However, suppose his next target salted their password. Even if the
attacker knows what the salt is, his precomputed table is
worthless—the salt changes the hash resulting from each password. He
has to re-hash all of the passwords in his list, affixing the target's
salt to the input. Every different salt requires a different
dictionary, and if enough salts are used, the attacker won't have room
to store dictionaries for them all. Trading space to save time is no
longer an option; the attacker must fall back to hashing each password
in his list for each target he wants to attack.
So, it's not necessary to keep the salt secret. Ensuring that the
attacker doesn't have a pre-computed dictionary corresponding to that
particular salt is sufficient.
After thinking about this a bit more, I've realized that fooling yourself into thinking the salt can be hidden is dangerous. It's much better to assume the salt cannot be hidden, and design the system to be safe in spite of that. I provide a more detailed explanation in another answer.
However, recent recommendations from NIST encourage the use of an additional, secret "salt" (I've seen others call this additional secret "pepper"). One additional iteration of the key derivation can be performed using this secret as a salt. Rather than increasing strength against a pre-computed lookup attack, this round protects against password guessing, much like the large number of iterations in a good key derivation function. This secret serves no purpose if stored with the hashed password; it must be managed as a secret, and that could be difficult in a large user database.
The answer here is to ask yourself what you're really trying to protect from? If someone has access to your database, then they have access to the encrypted salts, and they probably have access to your code as well. With all that could they decrypt the encrypted salts? If so then the encryption is pretty much useless anyway. The salt really is there to make it so it isn't possible to form a rainbow table to crack your entire password database in one go if it gets broken into. From that point of view, so long as each salt is unique there is no difference, a brute force attack would be required with your salts or the encrypted salts for each password individually.
A hidden salt is no longer salt. It's pepper. It has its use. It's different from salt.
Pepper is a secret key added to the password + salt which makes the hash into an HMAC (Hash Based Message Authentication Code). A hacker with access to the hash output and the salt can theoretically brute force guess an input which will generate the hash (and therefore pass validation in the password textbox). By adding pepper you increase the problem space in a cryptographically random way, rendering the problem intractable without serious hardware.
For more information on pepper, check here.
See also hmac.
My understanding of "salt" is that it makes cracking more difficult, but it doesn't try to hide the extra data. If you are trying to get more security by making the salt "secret", then you really just want more bits in your encryption keys.
The second approach is only slightly more secure. Salts protect users from dictionary attacks and rainbow table attacks. They make it harder for an ambitious attacker to compromise your entire system, but are still vulnerable to attacks that are focused on one user of your system. If you use information that's publicly available, like a telephone number, and the attacker becomes aware of this, then you've saved them a step in their attack. Of course the question is moot if the attacker gets your whole database, salts and all.
EDIT: After re-reading over this answer and some of the comments, it occurs to me that some of the confusion may be due to the fact that I'm only comparing the two very specific cases presented in the question: random salt vs. non-random salt. The question of using a telephone number as a salt is moot if the attacker gets your whole database, not the question of using a salt at all.
... something like a user name or phone number to salt the hash. ...
My question is if the second approach is really necessary? I can understand from a purely theoretical perspective that it is more secure than the first approach, but what about from a practicality point of view?
From a practical point of view, a salt is an implementation detail. If you ever change how user info is collected or maintained – and both user names and phone numbers sometimes change, to use your exact examples – then you may have compromised your security. Do you want such an outward-facing change to have much deeper security concerns?
Does stopping the requirement that each account have a phone number need to involve a complete security review to make sure you haven't opened up those accounts to a security compromise?
Here is a simple example showing why it is bad to have the same salt for each hash
Consider the following table
UserId UserName, Password
1 Fred Hash1 = Sha(Salt1+Password1)
2 Ted Hash2 = Sha(Salt2+Password2)
Case 1 when salt 1 is the same as salt2
If Hash2 is replaced with Hash1 then user 2 could logon with user 1 password
Case 2 when salt 1 not the same salt2
If Hash2 is replaced with Hash1 then user2 can not logon with users 1 password.
There are two techniques, with different goals:
The "salt" is used to make two otherwise equal passwords encrypt differently. This way, an intruder can't efficiently use a dictionary attack against a whole list of encrypted passwords.
The (shared) "secret" is added before hashing a message, so that an intruder can't create his own messages and have them accepted.
I tend to hide the salt. I use 10 bits of salt by prepending a random number from 1 to 1024 to the beginning of the password before hashing it. When comparing the password the user entered with the hash, I loop from 1 to 1024 and try every possible value of salt until I find the match. This takes less than 1/10 of a second. I got the idea to do it this way from the PHP password_hash and password_verify. In my example, the "cost" is 10 for 10 bits of salt. Or from what another user said, hidden "salt" is called "pepper". The salt is not encrypted in the database. It's brute forced out. It would make the rainbow table necessary to reverse the hash 1000 times larger. I use sha256 because it's fast, but still considered secure.
Really, it depends on from what type of attack you're trying to protect your data.
The purpose of a unique salt for each password is to prevent a dictionary attack against the entire password database.
Encrypting the unique salt for each password would make it more difficult to crack an individual password, yes, but you must weigh whether there's really much of a benefit. If the attacker, by brute force, finds that this string:
Marianne2ae85fb5d
hashes to a hash stored in the DB, is it really that hard to figure out what which part is the pass and which part is the salt?