Tag Info

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

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

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

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

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

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

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

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

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

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

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

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

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

4

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

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

4

That's a reasonable solution if you can't use a random salt. If you personalize your hash function for your application, then the salt is globally unique for each user. (e.g. use sitename||username as salt) The only salt reuse happening is that older passwords of the same user have the same salt. But that's a very minor issue. I disagree with Polynomial who ...

4

The purpose of a salt is to prevent multi target attacks. Rainbow tables are just one, rather overrated special case of multi-target attacks. A single salt won't prevent multi-target attacks. In your system that means than an attacker who isn't interested in attacking a specific user, can simply check his candidate password against all passwords at the same ...

4

For any value $x$ chosen randomly in a set of size $N$, and hash function $h$, publishing $h(x)$ allows for an exhaustive search on $x$ with average cost $N/2$. This is unavoidable. The problem with passwords is that, by virtue of fitting in the brain of a human, they tend to come for a set of potential passwords of relatively small size $N$. We try to cope ...

4

You cannot recover the password from the hash. That's not something that password hashes are designed for — quite the opposite: with a proper password hash, the only way to recover the password given the hash is to make a guess and verify it — and the better the hashing scheme, the more costly verifying guesses is. Passwords are used for authentication: a ...

3

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

3

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

3

The role of the salt is to be as unique as possible: two distinct instances of a stored password (for two distinct users, or two successive passwords for the same user) shall use distinct salt values. Preferably, this uniqueness should be worldwide: it is best if there is no salt collision even across two installations of the same software (or different ...

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