# Tag Info

18

The reason that salts are used is that people tend to choose the same passwords, and not at all randomly. Many used passwords out there are short real words, to make it easy to remember, but this also enables for an attack. As you may know, passwords are generally not stored in cleartext, but rather hashed. If you are unsure of the purpose of a ...

14

"In my system, there are no user names, only passwords." This is the real problem. Using the same value for both identification and authorization is usually a bad idea, for several reasons: Two accounts cannot have the same password. An on-line attacker needs only a single query to determine if any password in the system matches their guess; thus, ...

12

Usually, when the user registers, you will generate a random value to become the salt. Then, in the user database, you store the user's name, salt, and hash generated using the password and salt (and whatever else is relevant for a user table). Note that doing it this way allows each user to have a unique salt. Each user having a unique salt greatly ...

12

If your system already has some other unique user identifier (be it an ID, user-name, or an EmailAddress) is there any effective decrease in your security if you simply use that value as your salt? The salt in a hash actually forms two different purposes. Generally, it is acceptable for a salt to be known, so let us consider H() a hash function, S, some ...

12

A second reason that a hash is usually present in RSA signature schemes (apart from being able to sign long messages) is to prevent existential forgery attacks. These look like this: Assume we have the public key $n$, $e$. Choose some random garbage $s$ (smaller than $n$), and calculate $m = s^e \mod n$ (i.e. "RSA encryption"). If you used "text book RSA ...

9

Looking at the MSDN link given by Tangurena, they use the word salt in this paragraph (and the following ones): To prevent discovery of plain text content by comparing encrypted values (the second attack), most encryption algorithms include a salt value. Specifying a different salt value generates a very different encrypted output. When using the ...

9

In any public key system, you don't encrypt with private key. You encrypt with public key, or sign with private key. If your goal is signing (resp. encrypting) one small value with the RSA private (resp. public) key, keeping the signature small: forget about it, that's not directly possible. Under RSA, a cryptogram is always of size at least comparable to ...

8

Salts must be unique. Randomness (with a "good" random generator) is sufficient to ensure uniqueness. A per-user ID (e.g. the user login name) is not sufficient for uniqueness, because it does not capture some occurrences which do happen in practice: two users on two distinct systems (running the same software) which share the same ID (how many Joes and ...

8

This is not a limitation of the cryptographic functions, like SHA or PBKDF, since the zero byte isn't processed any differently. Since the purpose of a salt is generally to travel alongside a human password, libraries that handle the password as a zero-terminated string might also handle the salt as such a string. Obviously, a 0x00 in the salt would ...

8

Let's get terminology right. If you talk of "unknown s" then s is not a salt; when some piece of data is secret, we call it a key. And your "hash function" is then a MAC. In the context of "password hashing", such things are sometimes called "peppering" (as always, technical terminology is, at its core, a collection of bad puns). If your MAC is correct ...

7

The salt has two main purposes as I understand it. (1) To ensure that two users who choose the same password, get different password hashes. Say the CEO, and the janitor, choose the same password. Without a salt, they'd both get the same hash. This means that an attacker who managed to download the password file, could instantly see that the CEO, and the ...

7

This construction has two advantages over a plain hash of param1||param2: It's immune to length-extensions You can't get collisions of the form param1=A||B param2=C vs. param1=A param2=B||C. But neither of those is relevant to password hashing, so it doesn't offer any advantage there. The construction looks like it's inspired by HMAC:  HMAC(K,m) = ...

7

With the message padding scheme of SHA-2/SHA-256 as it stands (add one 1 bit, a minimal number of 0 bits so that the overall padded message will end on a block boundary, then the original message length over some fixed number of bits), I know no attack enabled by allowing a different IV. However, allowing an arbitrary IV renders ineffective one of the two ...

7

I'd use HKDF's "expand" step to generate multiple keys from one masterkey. Use PBKDF2 to derive that masterkey from the password and salt. i.e. replace the "extract" step of HKDF with PBKDF2. //Extract MasterKey = PBKDF2(salt, password, iterations) //Expand AES-Key = HMAC(MasterKey, "AES-Key" | 0x01) MAC-Key = HMAC(MasterKey, "MAC-Key" | 0x01) (where | ...

7

Identical passwords will still get unique PBKDF2 hashes given a unique salt, regardless of which mechanism you use. I don't think explicitly adding the salt improves the security of this scheme. The designer PBKDF2 have already considered and solved this problem. There is no need for you to try to duplicate their efforts. I think it's safer to use the ...

6

The answer to that depends on the details of your system, and specifically whether someone other than you can modify the hash. If you store the hash in your database, and retrieve the expected hash value from your own database to compare it with the actual hash (when checking to make sure that those certain values have not been altered), there's no point in ...

6

Well, the reason we add salt when hashing passwords is not to make a single hashed password stronger (it doesn't, except in a way I'll explain below), it's to fix up some weaknesses that appear when you have a collection of hashed passwords. If the attacker somehow gets a single hashed password, then adding a salt doesn't really slow the attacker down ...

6

In a scenario such as yours, where there is only one password/passphrase, but it is used as key material for the encryption of multiple CBC encrypted files, you will (as you noted yourself) obviously not make it any harder for an attacker to compute your password, should you use a salt. However, using a salt would mean that the encryption of each file is ...

5

Do I have to store the salt used on the specified password in the database so it knows what to use next time? Yes that is exactly correct. Salts are not secret values but they do need to be randomly selected (without bias) distinct. This is why using dates may require some care: they have low entropy. Dynamic salt doesn't mean the salt is changing ...

5

Looks right to me, assuming you know what the 10 salts are. If you don't know a priori what the salts are (which is typically the case when building a rainbow table), you'd have to compute for the entire salt space. This is where the big gain comes into play as for each additional salt bit, the storage requirement doubles. Thus you get exponential growth ...

5

There is an advantage. Cracking a password from its hash without knowing the salt is extremely difficult, as you're essentially increasing the password length by the length of the salt. If you're storing the hash in such a way that it isn't obvious that it's been salted by the application, the attacker likely won't go looking for it. If the application ...

5

If the hash function is a random oracle, then the salt can go wherever you wish, it will do its job. On the other hand, there is, arguably, no such thing as a random oracle. On an existing, real, tangible hash function, details on how you input things may or may not trigger slight structural weaknesses in the function, which could impair the role of the ...

5

In general you shouldn't mess with standard algorithms/protocols, because of the innumerable ways you can break semantic security, like adaptive chosen ciphertext attacks. Use optimal asymmetric encryption padding if you must roll something yourself.

5

Signing a hash is cheaper than signing the whole document. RSA is relatively costly, and, as long as the hash function is not weak, there isn't any practical difference in security between signing the whole plaintext and signing its hash, because the hash uniquely identifies the plaintext. Wikipedia says: There are several reasons to sign such a hash ...

5

No, it is not better. To send the salt encrypted, one would need a key and IV (another salt) to encrypt it. This adds unnecessary complexity as the security of the ciphertext does not depend on the salt being kept private. So, encrypting the salt adds negligible security yet adds a fair amount of complexity. Keeping things as simple as possible is often a ...

5

Let's try to avoid random per-password salts. If the only requirement for salt is to be unique, which is the case for good password hashing schemes, you'll need: $globalSalt$ is a secret random 32-byte string. $userId_n$ is a unique user identifier. You can use, for example, $HMAC$-$SHA256(globalSalt, userId_i)$ to generate salt for each user $i$. Or, ...

5

Edit: I missed a detail in the original question when writing the below. I compared the effects of including the salt in each iteration to including the password, but the original question asked about including the salt versus only iterating on the previous hash output. Mea culpa. My link to Thomas Pornin's answer to a related question contains an ...

5

Given that SHA-512 is used, there is no practical benefit to iterating hash = sha512(salt + hash) compared to iterating just hash = sha512(hash). For some parameters, it even weakens the scheme by a factor of nearly 2 against the attack that most matters: guessing the password. Let's first justify the weakening. Assume salt is 125 bytes. salt + hash is ...

4

At one past employer, we used some tables substantially like the following: The web app would switch out different algorithms based on which hash algorithm was being used. And if the hash used for a particular customer was now obsolete, they would be required to change their password, and it would update their row in the user table with the new hash. For ...

4

Basically, salting a password means that you compute a hash value which depends on the password and on a salt (a non-secret random value of sufficient length, e.g, 64 bits). Remember that salting a password allows to better resist attacks such as dictionnary attacks or time-memory tradeoffs (e.g., rainbow tables), i.e., attacks involving an offline ...

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