Is combining salt from two places secure enough and what length
Analeea last edited by
I need to implement some hashing scheme for an open-source project. This is what I currently have and I'd like to hear whether this is secure enough -
The password is hashed using PBKDF2-SHA256 (which I prefer over bcrypt simply because OpenSSL supports it natively) with 2048 iterations.
The salt is actually a concatenation of two strings - the first one is unique and stored in the DB along with the password in plaintext. The second one is shared and stored in plaintext in the program's configuration file. My logic is that this will prevent brute forcing passwords if an attacker gains access to the DB but not to the server's filesystem.
Is this secure? Also how long should each part of the two salt strings be? 16+16 bytes? 32+32 bytes?
That second part of the salt you are talking about actually has its own name - it's called a pepper. And as long as the real salt itself is always unique for each password, adding a pepper doesn't decrease security in any way (it arguably increases it in some scenarios).
Regarding the length of the salt, 16 random bytes* each will be more than enough. Since 16 random bytes is 128 bits of entropy, you can be sure there is practically no chance of your salt ever repeating for more than one password.
*Note that 16 random bytes means 16 random bytes of binary data, not a 16 character string. See Steffen Ullrich's comment