CODEWITHSUNDEEP
securityhashpasswordsbcryptsalt-cryptography
zeus
zeus

Reputation: 13345

Do we need to use a fixed salt with BCrypt?

Brypt generate a random salt for every password. This is ok to prevent rainbow table attack. But is this ok to prevent brute force attack ? I mean if the user choose a weak common know password, brute force attack can be made on well know password list. So my idea will be to concatenate the user password with a fixed salt and eventually also with a user id salt (ie: user pseudo). If the attacker don't have access to the code of the software (if he hack only the database) then he will not be able to find real password using brute force attack with well know password list.

so what the good way to do ?

Bcrypt(apassword)

or

bcrypt(apassword+pseudo)

or

bcrypt(apassword+pseudo+fixedsalt)

Upvotes: 1

Views: 1729

Answers (1)

martinstoeckli
martinstoeckli

Reputation: 24071

As you wrote, the salt prevents rainbow table attacks and doesn't help against brute-forcing, it's BCrypt's slowness which mitigates brute-forcing. BCrypt offers a cost factor, which controls the time necessary to calculate a single hash.

The additional protection you want can be achieved better by encrypting the calculated hash with a server side key (any algorithm like AES-256). The key doesn't become part of the hash then and can be exchanged whenever this is necessary. The advantage is the same as with your fixed salt (actually called pepper), only an attacker with privileges on the server can start cracking the password hashes. I tried to explain this at the end of my tutorial about safely storing passwords.

So let the salt do its job and do not mix it up with other tasks, instead encrypt the password-hashes afterwards.

Upvotes: 3

Related Questions