Do we need to use a fixed salt with BCrypt?

Question

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)

It's not an option, first it's not very easy to do (our app work in every language), second it's can boring the user and make it not complete the registration process. — zeus
– zeus, Commented Jan 23, 2018 at 11:23
thanks leone, but not really, i m not worry about brute force attack through api call (that we can easily block) but about brute force attack directly to the database the hacker obtained ... — zeus
– zeus, Commented Jan 23, 2018 at 11:39
The only thing that i can think of is randomizing the password hash order then so they cannot match it with their hash databases but i'll let more expert people in this field talk — F. Leone
– F. Leone, Commented Jan 23, 2018 at 11:42

martinstoeckli · Accepted Answer · 2018-01-24 07:50:18Z

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.

Collectives™ on Stack Overflow

Do we need to use a fixed salt with BCrypt?

1 Answer 1

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Linked

Related