# Tag Info

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

5

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

4

The construction you are proposing is called the "envelope" or "sandwich" MAC, it predates HMAC, and it is in fact secure—provided the key and message are appropriately padded. That is, $$\text{SHA256}(k \parallel m \parallel 1 \parallel 0^{b - 1 - (|m| \bmod b)} \parallel k)$$ is secure, as long as $k$ is the underlying hash function's block length $b$ ...

3

The article you linked to explains everyting Salt concatenated with i encoded as a big-endian 32-bit integer So, || is concatenation, INT_32_BE is a function that encodes the 32 bit integer i as big endian. On a big endian system, INT_32_BE would do nothing. On a little endian architecture, it would do the encoding. i goes from 1 to dklen/hlen. ...

3

If the existing salt is random (and chosen from a large enough space), there is little or no benefit to changing the salt each time the user changes their password. There's no downside -- you might as well change the salt each time the user changes their password; that is probably good practice -- but if you don't change the salt, it's unlikely that ...

3

No, they are not conceptually related. A keystream is the output of a stream cipher and is of (effectively, for modern ciphers) infinite length. If you need to encrypt more plaintext, you use the cipher to produce more bytes of keystream. On the other hand, password salts are of fixed size and their purpose is to make every password effectively unique. A ...

2

To sum up and expand on the previous answers and comments, if everything goes to plan salts may only need to be distinct, but in practice there are attacks that can be avoided by always generating a new salt whenever the password is changed. If an attacker gets access to multiple different password hashes with the same salt (due to multiple compromises or ...

2

From the Catena paper, version 2. A salt refers to an additional random input value for the password scrambler, stored together with the password hash. It enables a password scrambler to derive lots of different password hashes from a single password like an initialization vector enables an encryption scheme to derive lots of different ciphertexts from a ...

2

As Trevis says, it's at least as safe: there's a simple reduction from the salted to the non-salted MAC, assuming the latter is secure in the standard "existential unforgeability under chosen message attacks". Assuming the adversary has full control of the salt, it also won't buy you anything security wise. In a slightly different setting, where the salt ...

2

Safe, yes, but it doesn't really give you anything. The only use for a salt is to mitigate precomputation attacks against a password. Since it is public, it gives you no extra MAC security. By the property of the MAC, no adversary can forge one without knowing the key, and by the security of your KDF (which includes the salt) no one should be able to get ...

2

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

1

1

No it isn't a good way of salting and it isn't the standard way either. There is no reason or benefit to store the salt before it is used. The point of salt is just to prevent parallel and precomputation attacks. Storing it ahead of time means in an undetected compromise the attacker would learn of 'future salts' which undermine the precomputation ...

1

It is secure. The IV only needs to be indistinguishable from random to an attacker, and it is as long as the salt is random. There is one remark: if you extract more key + iv bytes than the hash function in PBKDF2 returns then the PBKDF2 function is executed twice. An attacker however only has to find the key, not the IV, so an attacker doesn't have to do ...

1

You could do something fairly simple, such as $UserSecret = Random()$ $UserID = HMAC(ServerSecret, UserSecret)$ Send the user the two values. When he reconnects, he sends the two values back. If re-calculating $UserID$ with the user's $UserSecret$ gives the same $UserID$ then that proves (to a high degree of certainty) that it's the same person that was ...

1

With a KDF meeting its objectives, the only way the leak of the persisted key compromises the confidentiality of the other is correctly identified in the question: a password guess can be checked at the cost of one evaluation of the KDF based on the leaked key and its corresponding salt (and assuming the password's entropy is significantly less than the ...

1

Some research brought up this paper On the Security of Two MAC Algorithms (Preneel and Oorschot, 1995). The authors state that it's possible to significantly reduce the claimed security so that the security is about the same as collision resistance instead of preimage resistance. The details can be read there and in the references.

1

Passwords should use a password hashing function. Password hashing functions are different from basic cryptographic hashes, though they use cryptographic hashes as part of their construction. Password hashing functions must use salt. (Password hashing functions can also tune their time and/or memory usage, cryptographic hashes generally can't.) So for your ...

1

The salt isn't key, it wasn't a secret. In the original UNIX password encryption a 12 bit number derived from rand() calls was used to transpose the first 12 and the third 12 entries in a copy of the DES algorithm's E Permutation table. The salt was store in the password field of the password file, the trailing two characters, each one of a set of 64 ...

1

Salts are generally stored in the database with the password. They shouldn't be timestamps, salts should be random values of 128 bits or more (though this may vary depending on the hashing scheme used.) Salts improve security by making brute force attempts single-use: a password of "password" is likely going to be used many, many times. If it's hashed ...

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