Hot answers tagged

66

The salt is stored in plaintext next to the hash and the same salt is used when checking a password. Its purpose is to slow down attackers who obtained a copy of the database: They must attack each password on its own (they need to try each input for each hash instead of trying each input and comparing the output to all hashes at once). They can't make use ...


45

The hash returned by bcrypt.hashSync is more than the hash itself, it contains all parameters needed by bcrypt. You do not need to store anything else yourself, this information is everything bcrypt needs to hash and compare an incoming password. The actual hash was computed by combining the password and salt, so no worries there. The structured data is ...


24

The whole point of a salt is to be unique to a set-password operation, so that attackers can't reuse work when they target multiple accounts (multiple users on the same server, multiple servers, or both). Using the password as the salt completely defeats the purpose. The salt does not need to be unguessable or secret. The reason it's almost always a long-...


23

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


22

Since this is still open and the issue keeps coming up: TLDR: There are lots of things in OpenSSL that implement standards including AES, but the key derivation part of enc is partly nonstandard (at least by default) First, OpenSSL has several commandline operations it calls commands (although they usually aren't separate programs, as typical commands are ...


17

Can you help me understand what a cryptographic “salt” is? In the context of password creation, a "salt" is data (random or otherwise) added to a hash function in order to make the hashed output of a password harder to crack. When might I need to use it? Always. Why should or should I not use it? You should always use a salt value with your hash ...


16

The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key". In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily occur client-side. ...


15

Direct Answers What is the mechanism that creates the salt, juxtaposing it to the hash, and make[s] sure the password will comply to the hash+salt combination? What creates the salt? - A random number generator, used when a user's password is being generated or changed. What juxtaposes that salt beside the hash? - How exactly to store the results of that ...


13

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


13

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to ...


13

Assume you have an IND-CCA secure cryptosystem $E$ that runs a password through a slow KDF and implicitly handles salts and random IVs, a human-chosen password $p$, and messages $m_1$ through $m_n$ to encrypt. Is $E_p(m_1+m_2+\cdots+m_n)$ or $E_p(m_1)+E_p(m_2)+\cdots+E_p(m_n)$ better for this? Each invocation of $E$ is slow due to it running a KDF on $p$, ...


11

Gilles already explained it sufficiently but using a unique salt brings another advantage: Users with identical passwords will not have identical hashes stored in the database. Unfortunately not all people use safe passwords and many use identical passwords. Knowing that a certain system is not using unique salts but instead using the actual password as a ...


10

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


10

My understanding of the term 'pepper' is that it more matches your definition 2, in that a pepper is an unknown salt, which makes it a cryptographic secret, but not a key. However, in use it is not as limited by either of your definitions: The pepper can be different (or random) for all users (like a salt). The pepper can be the same for all users (like a ...


9

Answering your question If an attacker have access to a copy of my users database table containing each salt and the related salted password, I can't understand how a CSPRNG would be more secure than a SHA12 hashed UUID. Can someone elaborate? I’m not sure if you only have read the question “Cryptographically Secure Pseudo-Random Number Generator in Qt/C++ ...


8

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


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 (i.e....


7

I'm going to attempt to answer a part of your question that has so far been neglected: when I might need to use it and why I should/should not use it. The short answer is that, as an amateur, you should not be using cryptography at a level that requires dealing with salts directly. For instance, the bcrypt password hashing algorithm uses salts ...


7

So, here's my question: is there a point where the salt size doesn't matter anymore in terms of security and where it might even decrease it? The purpose of a salt is to prevent the attacker from targeting multiple users' passwords with the same try or caching common passwords' hashes in a table. You need enough salts that each user has a unique salt. After ...


7

From looking at the source or 7zip that seems to be the case. The format has a place for a salt, as SEJPM's link shows. It is mixed into the homebrewn iterated SHA-256 hash before the key. The 7zip decoder even seems to support salts. However, the encoder never uses a salt. Oddly there is even code for generating a random 4-byte salt, but it is commented ...


7

PBKDF2, like most password-based key derivation functions, has a salt input because that is often useful. Two examples: When using PBKDF2 as a key derivation function, the salt allows to re-use the same master key for multiple derived keys, e.g. a confidentiality key and integrity keys, with a different salt per use. In the same vein, PBKDF2 could be used ...


6

Usually the salt is stored with the hash. Let's say we have a table users with the field password. The hash is generally written concatenated with the salt (divided by a separator like :) So the final field value will be something like cbc0a790b2f28fc72ca43eb749028b9f:21022011 Note that the salt should always be in cleartext (or being reachable in some ...


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

Thomas Pornin has already answered your question accurately, but I'd like to add a strong warning to the discussion. You should probably not be computing password hashes client-side. In the most naïve approach, completely eliminates most of the value in password hashing. By computing hashes on the client and simply comparing their equivalence server-side, ...


6

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


6

My question is: does it add any security to add a random salt to the message you are validating with HMAC? This depends on what the HMAC is used for. If you use a key to sign more than one secret message, a salt will prevent an attacker from knowing whether two of them are equal. (Or brute forcing a message if the key is revealed...) It is more common ...


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

512 bits is overkill for even global uniqueness. 256 bits should be enough, with a good random number generator: even if every person on earth generated one every nanosecond, it would take a million million years to reach the birthday bound. However, I agree that global uniqueness is a good idea. If anyone anywhere uses the same salt and password hash (or ...


6

You are correct that the function of using a distinct salt for each user is to thwart any batch advantage an adversary attacking one of many targets might have gotten out of precomputed tables. If there are $2^n$ distinct salts and they're chosen uniformly at random for each user, it's only around $\sqrt{2^n} = 2^{n/2}$ users that a collision in the salts ...


6

The assumption seems to be that the adversary wants to confirm a guess of $\mathtt{value}$ given $\mathtt{hash}=\operatorname{SHA-256}(\mathtt{value}\mathbin\|\mathtt{pepper})$, for unknown random secret $\mathtt{pepper}$. This is an ad-hoc PRF of $\mathtt{value}$ with symmetric key $\mathtt{pepper}$. No, the small size/entropy in $\mathtt{value}$ is not an ...


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