Tag Info

Hot answers tagged

32

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


16

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


13

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


13

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


10

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


10

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


9

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


9

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


9

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


9

I don't see any obvious security problems in your approach. You can look into key derivation functions, that can provide some additional security in case one of the following occurs: Your password leaks Your secret number leaks A weakness is identified in the hash function There is a few usability issues, that would have to be addressed as well: ...


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

Yes, you need to use the same salt each time you use a hash created with that salt. Typically a pseudorandom salt is generated for each user, and stored alongside the hash. Many hashing libraries (for example, bcrypt) create hashes with the salt embedded in them.


8

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


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


8

If the attacker had already begun creating a rainbow table or is engaged in some other attack which requires knowledge of the salt, then a password change with a salt change will require the attacker to start from scratch. Always assume the attacker has before and after copies of the password hash and salt. If the salt is not changed, any work the attacker ...


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

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


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

There are some attacks on hashes keyed with a secret suffix. The proper primitive for deriving a secret from keys/passwords and an identifier is a key derivation function. In your case, if the secret number is random a fast key derivation function, like HKDF, would be enough to expand the key into several site-specific hashes. In that case there's no need ...


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


6

The resume of that other answer could be: When you have a password hashed, it's hard (very hard) to find out what was the original password: you have to try all combinations, until you find the hash. That's brute-force. Someone can speed up a bit this process, by pre-computing many passwords: he'll store all those passwords / hashes, and will try to find ...


5

Don't bother with changing the actual cipher algorithm. Read about Kerckhoffs's principle: you should only change things like the key and the IV, not the actual algorithm. In order to test your avalanche, flip one bit in your key. That should change about half the bits in your output. For cipher design, Applied Cryptography has already been suggested. ...


5

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


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

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

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

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.



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