Tag Info

Hot answers tagged

323

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


223

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


221

The output of MD5 is binary: a sequence of 128 bits, commonly encoded as 16 bytes (technically, 16 octets, but let's use the common convention of bytes being octets). Humans don't read bits or bytes. They read characters. There are numerous code pages which tell how to encode characters as bytes, and, similarly, to decode bytes into characters. For almost ...


78

I'm not sure where you are from. First of all his opinion is against the the considered industry best practice as defined by NIST. Furthermore your manager is dangerously wrong. The more users the more likely it is to get the same passwords for several users. Also the following companies do it and I'm quite convinced that they have a larger global user base ...


70

The assumption is already wrong. Even if every password was unique, you'd still need salts. Without salts, the attacker can go through his list of possible passwords just once, compare the hash of each guess and check if the result matches any of the stored hashes. In other words, the attacker only needs a single calculation per guess. This has nothing to ...


60

In some circumstances, peppers can be helpful. As a typical example, let's say you're building a web application. It consists of webapp code (running in some webapp framework, ASP.NET MVC, Pyramid on Python, doesn't matter) and a SQL Database for storage. The webapp and SQL DB run on different physical servers. The most common attack against the database ...


53

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


50

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


47

You see that thing up there where it displays your username? They can't do that if the username is stored hashed now can they? One word, usability.


42

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


42

As Mike and Gumbo have mentioned in comments, a salt isn't intended to add protection to bad passwords. It's meant to keep the attackers from breaking the whole database at once. The length of the salt isn't meant to add difficulty to breaking the stored passwords. It's meant to ensure that your salt is reasonably unique compared to others on the Internet, ...


39

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

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


32

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


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


30

The main purpose of salts is to prevent an attacker from saving work by comparing a single calculated hash with all stored hashes. This problem is independent from whether or not the passwords are unique. Without salts, the attacker can simply go through his list of possible passwords, calculate the hash for each one and then check if the result matches any ...


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


28

Salt aren't there to prevent those. Salts are there to prevent attacks using rainbow tables, which are basically lists of hashes and their passwords. This is when an attack already has your password hash.


28

It is not a problem if the attacker learns the salts. Salts are not meant to be secret. What is important for a salt is that it is unique for each hashed password instance (i.e. not only a unique salt per user, but the user's salt must be changed when the user changes his password). If you think of your salt as something that may be shared between ...


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


26

The "best" counter-argument depends on what you are trying to achieve. If you just want to be scientifically right, then it suffices to say that salts are not, and never have been, a method to cope with two distinct users choosing the same password. In particular because two users who happen to choose the same password is not a problem to begin with, so ...


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


23

Technically you can still use a rainbow table to attack salted hashes. But only technically. A salted hash defeats rainbow table attacks, not by adding crypto magic, but just by exponentially increasing the size of the rainbow table required to successfully find a collision. And yes, you'll need to store the salt :)


23

It is frighteningly frequent that many users use the same password. Two years ago, Yahoo lost passwords to half a million accounts. According to the password project, only 77% were unique. These were the most frequent passwords and the number of users who used them: | Word | Count | +-------------------+ | 123456 | 1667 | | password | 780 | | ...


22

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


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


22

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


21

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


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



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