716
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 reversed ...
398
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:
$ echo -n baseball | sha1sum
a2c901c8c6dea98958c219f6f2d038c44dc5d362
Theoretically it's impossible to reverse a SHA1 hash. But go do a google search on that exact ...
257
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 ...
179
Not storing the salt is bad advice.
The main purpose of a salt is that each user password has to be attacked individually.
If you do not store the salt then, as you said, you need to try every single salt combination in order to validate the password. If you need to check every single salt combination, this means that the salt cannot be too long (you ...
126
A 'secret' salt is known as a pepper.
From Wikipedia:
A pepper can be added to a password in addition to a salt value. A pepper performs a similar role to a salt, however whereas a salt is commonly stored alongside the value being hashed, for something to be defined as a pepper, it should meet one of the following criteria that define it a more carefully ...
117
You should store it in a single field. Do not try to divide it into parts.
I know this might seem a bit unintuitive for people comming from a database background, where the modus operandi is to normalize data and using serialized strings is considered an ugly hack. But from a security practice, this makes perfect sense.
Why? Because the smallest unit the ...
106
Users often use the same passwords on multiple sites. Your site might not have any financial data, but what if the same password is used for their bank, or for an online store?
You could argue that this isn't your problem, but it is a common issue, and is why whenever a breach happens, one of the immediate statements is "change your password, and change it ...
101
This would probably be explained in the auditory lecture that these slides accompany.
My guess is that he's calculating this assuming that users generally enter their correct passwords. You only need to cycle through options for r until you find one that produces a correct hash.
If you've been given the correct password, then you will come across an r that ...
94
You are trying to solve a problem that you shouldn't have in the first place: Password Reuse
The concept is simple. You think of a "good" password and use that for everything. Your bank account, online shopping, your e-Mail provider, etc.
The problem is, if it gets leaked by any one of them, then all of the other accounts are potentially in danger. This is ...
80
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 ...
78
A salt is not meant to be secret, instead, a salt 'works' 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 salt ...
70
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.
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
Have I Been Pwned? allows anyone to download the full database to perform the checks locally.
If that's not an option, using the API is safe, since it uses k-anonimity which allows you to perform the check without transmitting the full password / hash.
58
How are plaintext and hashes compared?
During the brute force attack, words from the dictionary are hashed with the correct hash algorithm and salt, and then compared to the hash in the database dump. So the attacker needs to know not only the hash value itself, but the algorithm and the salt.
How does the attacker know the salt?
The salt is generally ...
54
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 ...
49
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 ...
48
Good question, and I'm glad you asked it. I want people to find this thread when they Google it so they -- hopefully -- won't make the same mistakes that many other companies make.
You shouldn't just hash passwords, you should salt them and make sure your hashing algorithm uses some form of SlowEquals. You shouldn't stop there: you should use a secure ...
48
What you're missing is that hashes work on the original data, minus the original string. When you want to validate a string against a hash, you take the supplied string, plus the original hash data (cost, salt, etc) and you generate a new hash. If the new hash matches the old one, the string is then validated (in other words, the string is never decrypted, ...
47
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 :)
47
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, ...
45
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) ...
44
Seed:
Encryption is powered by random numbers, but how do you generate a truly random number? The current millisecond? The number of processor threads in use? You need a starting point. This is called a seed: it kicks off a random number.
Salt:
When you hash a string, it will always end up with the same hash.
foo = acbd18db4cc2f85cedef654fccc4a4d8 ...
38
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 ...
38
Is the random salt saved somewhere to be used for each encryption?
Yes
Seems less secure to me if the salt is saved right alongside the hashed password, rather than using some kind of computed salt an attacker would not inherently know if they got a hold of your data.
It's not, because the only thing a salt does and was invented to do is, as you said:
...
37
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. ...
37
While what Terry is saying is true, sometimes login systems actually hash the username (but without salt). They have you pick a login name and a display name. The login name is stored hashed (without salt because you need to be able to look it up) and the password is salted. The display name is different from your login name (because this should be kept ...
34
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 ...
34
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, resulting ...
33
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 (...
Only top voted, non community-wiki answers of a minimum length are eligible
