747
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 ...
403
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 ...
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 ...
176
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 ...
118
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 coming 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 ...
107
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 ...
100
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 ...
95
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 ...
82
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 ...
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 ...
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 ...
64
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 stored ...
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.
50
You have conflicting requirements here. The compatibility requirements forces you to keep the old hashes. The security requirements forces you to drop them. You will have to make a choice here about what requirements to fulfill.
If you decide to keep the backwards compatibility, try making the best out of a bad situation:
The old hash and the new hash ...
49
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 :)
49
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 ...
49
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
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, ...
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 ...
43
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:
...
39
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 ...
37
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 (...
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. They ...
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
Your second "salt" is a concept which has been described as "peppering". Basically, it works, but has the drawback of implying key management (the "pepper" being really what cryptographers would call a secret key): when you update the software, or switch to newer machines, you have to take care of transferring the pepper value, otherwise you will make all ...
Only top voted, non community-wiki answers of a minimum length are eligible
