Timeline for SCrypt's goal and the role its salt plays
Current License: CC BY-SA 4.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Feb 19, 2022 at 7:01 | comment | added | Polynomial |
Example of weakened security from the use of a pepper: bcrypt(pepper+salt+pass) with a 32 char pepper, 32 char salt, actually means only the first 8 characters of the password are used for the hash, because the BSD implementation of bcrypt silently truncates inputs to 72 bytes. (side note: use argon2id if you can)
|
|
Feb 19, 2022 at 6:57 | comment | added | Polynomial | The use of a secret salt, or "pepper", only makes sense in a threat model scenario where an attacker can access the location in which the password hashes are stored, but not the location in which the pepper is stored. The most common implementation is a single very long pepper string stored in a config file, applied to all passwords, to make it impossible to crack passwords if a breach was limited to SQL injection. The downside is that it adds implementation complexity, and that can introduce bugs which can weaken security (and there are real-world examples of this happening). | |
Feb 19, 2022 at 6:52 | comment | added | Polynomial | To clarify further: the purpose of a salt is to ensure that two equal passwords for two different users do not produce the same hash, thus revealing one user's password to the other, and to prevent mass precomputation of hashes so that hashes can just be looked up in a database to recover the plaintext (this is what rainbow tables used to do). For these purposes, the salt is only required to be unique, or very likely to be unique - it does not have to be secret at all. This answer may help with broader context: security.stackexchange.com/questions/17421/how-to-store-salt/… | |
Feb 19, 2022 at 2:58 | comment | added | bk2204 | The salt will be required to reproduce the password. However, the salt is cryptographically assumed not to be secret. If you're using a secret salt, then that's called a pepper. You may choose to use both if you like. | |
Feb 18, 2022 at 22:59 | comment | added | Neev Penkar | Thanks @bk2204, for your answer. So just one more query; will the system be more secure if I restrict the access to the salt? The real question is, can an attacker easily and feasibly form the end derived key with the right password but the wrong salt? If it not possible, then to make a password-based system more difficult to break into, I can encrypt the salt in many ways and thus make attacking a password a two part effort instead of a single part one, where the salt can, for example, be encrypted by the server or an application, and be decrypted only for authentication. | |
Feb 17, 2022 at 22:00 | comment | added | bk2204 | Right, I think my answer covers that in "since we could reuse or precompute guesses". The first sentence addresses the general use of the use of a memory-hard function in conjunction with a random salt. | |
Feb 17, 2022 at 9:58 | comment | added | Royce Williams | The goal of salting is resistance to precomputation. security.stackexchange.com/a/174555/6203 | |
Feb 17, 2022 at 2:20 | history | answered | bk2204 | CC BY-SA 4.0 |