Hot answers tagged salt
210
TL;DR - You can store the salt in plaintext without any form of obfuscation or encryption, but don't just give it out to anyone who wants it.
The reason we use salts is to stop precomputation attacks, such as rainbow tables. These attacks involve creating a database of hashes and their plaintexts, so that hashes can be searched for and immediately ...
46
You have a fundamental misconception of how rainbow tables work.
A rainbow table or a hash table is built by an attacker prior to an attack. Say I build a hash table containing all the hashes of strings below 7 characters for MD5. If I compromise your database and obtain list of hashes, all I have to do is lookup the hash on the table to obtain your ...
38
The distinction is arbitrary. A salt-aware algorithm works by taking input data and scrambling it in various ways, and there is no method for inserting the salt which is more or less "fake" than any other.
Trying to devise a password processing algorithm which is efficient on a general purpose CPU but does not scale well on a GPU (or a custom FPGA or ASIC) ...
35
(Note: using a salt is only half of the job; you also need to make the hash function slow -- so that attacking a single low-entropy password is still difficult. Slowness is usually achieved through multiple iterations, or hashing the concatenation of 10000 copies of the salt and password.)
What your "pepper" does is that it transforms the hash into a MAC. ...
35
A salt is not meant to be secret, instead, a salt 'works' by by making sure the hash result unique to each used instance. This is done by picking a different random salt value for each computed hash.
The intention of the salt is not compromised when it is known; the attacker still needs to attack each hash separately. Therefore, you can simply store the ...
33
Yes and no.
Salt protects you against someone obtaining your database and deducing the actual passwords even though they are hashed. (If someone steals your entire database, it is likely that they have also obtained the user data that the passwords were supposed to protect in the first place, but let's assume that passwords are even more valuable than use ...
30
None of the existing answers cover the critical part of this question to my satisfaction: what about the salts?
If just the password hash values were posted, other crackers can't possibly know:
The actual per-password (supposedly random, per the source) salt value.
How the salt is mixed with the password in the code.
All they have is the final, ...
28
A rainbow table is an optimization for reversing hashes by brute force. It works by a trade-off: you do a lot of precomputation to build a huge data structure, and you can then crack many hashes quickly.
A rainbow table only helps the crack hashes in the search space that it covers. Concretely, rainbow tables are built for plaintexts made of printable ...
27
Krebs follows up on this question, and Ptacek does clarify what he meant:
BK: Okay. So if the weakness isn’t with the strength of the cryptographic algorithm, and not with the lack of salt added to the hashed passwords, what’s the answer?
Ptacek: In LinkedIn’s case, and with many other sites, the problem is they’re using the wrong kind of algorithm. ...
26
Let's look at the salt question first, and then at the speed issue:
Salt, dictionary attacks and rainbow tables
A salt massively helps against dictionary attacks in the common case of an attacker getting access to more than one password hash.
Without a salt, an attacker will sort all the hashes. He will hash the first word from the password dictionary, ...
23
To answer this, one has to understand why salts are needed in the first place. This is explained pretty well in How to securely hash passwords?; here's an excerpt from the accepted answer:
Salts: among the advantages of the attacker over the defender, is parallelism. The attacker usually grabs a whole list of hashed passwords, and is interested in ...
21
While what Terry is saying is true, sometimes login systems actually hash the username (but without salt). They have you pick a log in name and a display name. The logging name is stored hashed (without salt because you need to be able to look it up) and the password gets salted. The display name is different from your login name (because this should be kept ...
20
Yes, there is a valid distinction to be drawn; you would need a cryptologist to tell you how meaningful the difference is.
A "real salt" as you've described is used to "perturb the encryption algorithm". I vaguely understand that, but not well enough to describe properly. Suffice it to say that with a real salt, the original password text is enciphered ...
19
Salt doesn't protect you against a lone attacker who is only after one password. An attacker who just wants to break one password will calculate hash(salt + guess) instead of hash(guess) (if the password scheme is hash(salt+password)).
Salt helps if the attacker wants to break many passwords. This is usually the case. Sometimes the attacker is attacking a ...
19
The classical recommendation for a salt for password hashing is:
A random value of 128 bits or more;
obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
unique for each entry (i.e. don't re-use the same salt, generate a new salt for each new password);
stored in plaintext in the database (so ...
18
No. A salt is simply supposed to be unique so that you can't use an attack (such as rainbow tables) that computes a password hash once and uses that result against multiple password hashes.
If you're interested in making reversing the hash impossible without some secret knowledge, then append a site-specific password to the provided password (in addition to ...
18
The answer is simply; the salt is stored alongside the password hash. A typical database scheme would look like;
uid | username | password | password_salt
-----|-------------|------------------|--------------
0 | alice | 862a6c81b7f8361b | 71e9c02731
The salt is not a secret. It is there to make certain types of attacks orders of ...
17
If you use the password as "salt" then you are not using any salt at all; you are just hashing the password.
If two users choose the same password, they end up with the same hashed password. That's what is often told as if it explained the problem, but it seems that most people get it wrong. They imagine that this means "collision", which, for some reason, ...
16
You are correct, however that doesn't change the fact that it is essential to use a salt. In this case attackers got hold of the hashed passwords, so they could either use a rainbow table or start a brute force or dictionary attack.
A rainbow table will get you all the passwords (up to the size and complexity in the table) in a very short space of time.
...
16
It does add one significant thing. If they steal the database, they have the username, per-user random salt, and hashed password. But they still don't have the original password. To reverse the hash, they will generally have to do a significant amount of separate work for each user.
Without any salt (a very bad idea, as LinkedIn learned), attackers can ...
16
You are fundamentally correct that it is just making the password longer but there are some additional things that it does add. Also the average password is not that long or secure and adding length "for free" is rarely bad. The salt makes it so that an attacker can't hash "password" once and then look for every user that has a password of "password".
...
15
Edit: All of the below assumes that the salts are known, because that's the industry-standard use of the word salt (3rd line).
Just as an example of how this often looks in the database, have a look at this SHA-256 Unix Crypt output:
$5$rounds=80000$wnsT7Yr92oJoP28r$cKhJImk5mfuSKV9b3mumNzlbstFUplKtQXXMo4G6Ep5
.. where wnsT7Yr92oJoP28r is the salt in ...
14
The unique purpose of the salt is to be unique: no two hashed passwords shall use the same salt value. This is meant to prevent cost sharing such as precomputed hash tables.
Uniqueness should be worldwide. For instance, suppose that you used a simple counter as a salt. Correspondingly, the value "1" will be used as salt for the first created account, ...
14
The salt can and should be stored right next to the salted and hashed password. Additionally, the salt should be unique per password.
Its purpose is to make it unfeasible to attack a leaked password database by using precomputed tables of password-hash-pairs.
That works because the salt only becomes known to the attacker as soon as he gets the actual ...
13
Salts don't help prevent someone from cracking a particular password. They help prevent someone from cracking many passwords at once using a rainbow table.
Say you have the following users on your site (the password wouldn't actually be stored in the database, just the hashed version).
USER PASSWORD HASHED PASSWORD
...
13
I posted an answer that explains this on another question, which should give give you a good background to all the major security concerns around password storage.
To answer your question more directly - a salt:
must be unique.
should be unpredictable.
should be unknown to potential attackers.
The problem with schemes like H(pass + username) is that the ...
13
This seems misguided.
Time in seconds from any source lacks almost any entropy, and is almost immediately guessable. If your OS allows microsecond granularity for a running process, you'll get 4 or 5 bits of entropy there, from the lower bits, but a lot less if someone finds a way to get the exact system uptime.
You're then talking about MD5, which isn't ...
12
Using the login name as salt is common but not really recommended: it does only part of the job. The point of a salt is to be as unique as possible among all instances of hashed passwords, so as to thwart any attempt as parallel attacks (attacking several hashed passwords simultaneously, using precomputed tables such as rainbow tables... are parallel ...
12
It depends on the hash function.
With a random oracle (which is the "ideal hash function"), there is no difference on how you put together salt and password at all, as long as both go in.
With real live hash functions there might be differences on the position of the input (like, there are extension attacks).
But then, you usually want to use some special ...
10
What this article could have meant is that putting the salt somewhere in the middle of the password supposedly increases the chance of being cracked by a dictionary attack or by brute force, because the rules to actually compose the same hash could not be implemented in your password cracker of choice. In reality, this is probably complete nonsense.
How ...
Only top voted, non community-wiki answers of a minimum length are eligible
