# Tag Info

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

22

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

21

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

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

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

14

First, realize that PBKDF2 is PKCS #5 is RFC 2898, i.e. http://www.ietf.org/rfc/rfc2898.txt It's essentially an algorithm to securely hash a password as many times as you want, with whatever hash you want. OWASP recommends hashing the password at least 64,000 times in 2012, and doubling that every two years, per https://www.owasp.org/index.php/...

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

12

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

11

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

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

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

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

7

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

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

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

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

No, it should not be necessary to derive a unique key for each message, although it certainly shouldn't do any harm, either. CBC mode is provably secure (in the IND-CPA sense, or even IND-CCA2 if combined with a MAC) even if the same key is used for multiple messages, as long as the underlying block cipher is secure (a PRP) and the IVs are distinct and ...

6

Password based key derivation functions generate a key suitable for ciphers from a given password. It relies only on the original password being kept secret. The purpose of the salt is simply to prevent the use of rainbow tables. A rainbow table would have to be made for each salt, and if (as is common practise), each user has their own salt, a rainbow ...

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

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