New answers tagged salt
There ARE a scenarios where adding the pbkdf2_hmac_sha1 step might be damaging to security. That includes an adversary having instrumented that step to log the input as part of another attack; or a successful side-channel attack on that step (e.g. using a less-privileged process on the same CPU). Multiplying the crypto algorithms increases the attack ...
Considering we have seen unintentional (and intentional?) bugs in crypto recently, I think it would be prudent to chain together different algorithms and sources of entropy, if possible.
PBKDF2 is designed for low-entropy passwords. Assuming your key is generated by a CSPRNG, then running it through PBKDF2 is redundant. I don't, however, believe it could be weaker than the original key.
Problem statement You have a list of messages $(m_1, m_2, \dots, m_n)$, possibly with corresponding tags/descriptions $(t_1, t_2, \dots, t_n)$, that you want to store. You want to protect confidentiality of the messages (but not the tags/descriptions) against an adversary that compromises your storage. You have a single secret passphrase $pw$ at your ...
If the salt value is not secret and may be generated at random and stored with the password hash, a large salt value prevents precomputation attacks, including rainbow tables, by ensuring that each user's password is hashed uniquely. This means that two users with the same password will have different password hashes (assuming different salts are used). In ...
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 ...
Top 50 recent answers are included