1

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)
zeus
  • 12,173
  • 9
  • 63
  • 184
  • Force the user to enter a secure password? – F. Leone Jan 23 '18 at 11:19
  • 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 Jan 23 '18 at 11:23
  • Then [this](https://stackoverflow.com/questions/15798918/what-is-the-best-method-to-prevent-a-brute-force-attack) might help – F. Leone Jan 23 '18 at 11:35
  • 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 Jan 23 '18 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 Jan 23 '18 at 11:42

1 Answers1

3

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.

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87