Tag Info

Hot answers tagged

273

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 ...


169

It typically works like this: Say your password is "baseball". I could simply store it raw, but anyone who gets my database gets the password. So instead I do an SHA1 hash on it, and get this: a2c901c8c6dea98958c219f6f2d038c44dc5d362 Theoretically it's impossible to reverse a SHA1 hash. But go do a google search on that exact string, and you will ...


49

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 ...


44

(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. ...


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) ...


37

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 ...


35

Salts and IV are not the same thing; salts are for password hashing, IV are for starting up some encryption modes. Neither is meant to be secret, though; otherwise we would call them "keys". It is safe to put the IV and/or salt in file headers. Your adding of "a few random data (256 bits, just to muddy the waters)" is the computer equivalent of sacrificing ...


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 ...


31

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, ...


29

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. ...


29

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

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, ...


24

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 ...


22

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 ...


21

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 ...


21

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 ...


20

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 ...


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 ...


20

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 ...


19

It is not added after the hash. It is added before the hash, so the hash is completely different for every salt. It isn't hash abcd = defg store 123defg (for user with 123 salt) and 456defg (for user with 456 salt) It is hash 123abcd = ghij hash 456abcd = klmn


18

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, ...


17

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. ...


17

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". ...


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

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 ...


16

What's the threat model? It could be of benefit to protect the password storage with an application-side secret, but only if you think it's a realistic scenario that your database is going to get compromised—without your application server, which holds the secret, also having been compromised. Usually, the application layer is considered the more vulnerable ...


15

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, ...


15

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 ...


15

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 ...


15

You want the salt to be unique. You also do not want the salt to be "revealing" because you will store it "as is", as clear text, on the database server. A salt needs not be secret, but people may get nervous if you store, unprotected, some value which they feel ought to be secret -- and this includes their mother's maiden name, which is apparently used by ...



Only top voted, non community-wiki answers of a minimum length are eligible