407
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 ...
259
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 ...
177
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 ...
127
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 ...
121
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 ...
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 ...
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 ...
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 ...
72
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 ...
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 ...
61
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.
61
The hash and salt are both in the value column. After Base64 decoding, the first 32 bytes are the hash, and the rest is the salt (in your case, it's the ASCII string seldemer).
answered May 4 at 15:18
Joseph Sible-Reinstate Monica
6,1542 gold badges20 silver badges32 bronze badges
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
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, ...
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, ...
46
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 ...
45
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:
...
45
The important part
The fact that you are generating salts on your own is a red flag. The best way to do this, especially if you have little experience with security, is to use an established library for password hashing.
A well-designed library will generate and use salts automatically for you, and it will store the salt and the hash in the same string, that ...
40
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
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 ...
32
There are lots of known cryptographic weaknesses in MD5 which make it unusable as a message digest algorithm, but not all of these also apply in the context of password hashing. But even when we assume that these do not exist, MD5 is still a bad password hashing algorithm for one simple reason: It's too fast.
In any scenario where an attacker obtained the ...
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
The news is full of examples of leaked databases (this is just the most recent results).
The How:
The vast majority of cases involve unsecured databases/backups (across pretty much all technologies: S3, mongodb, cassandra, mysql, etc....). These are usually due to configuration errors, bad defaults, or carelessness.
What data is leaked:
These generally ...
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 passwords,...
27
bcrypt would be a somewhat better approach because it is designed to be (programmably) slow.
Using a large enough salt and a reasonable complexityFactor, bcrypt(salt + number, complexityFactor) should yield a viable hash and you avoid "rolling your own cryptography", which could possibly turn out to be a difficult sell. To increase security you just crank ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible