2

I'm making an app and am using bcrypt to encrypt passwords.

I've no prior knowledge about bcrypt and still don't know much, I know it supposed to be a secure cpu-intensive encryption.

After implementing it yesterday I noticed my sign up's becoming extreemeelyyy slow, taking about 5-10 seconds to complete. I'd thought it was just my slow computer (running the server) however after inserting a few break points on the server, I noticed it was stopping while hashing the password.

I tuned down the rounds from 15 to 1, and everything started working smoothly.

I also checked the database to see if maybe the password was the same/similar to the input password, it seem's just as random - then again I'm a human and not a brute forcing bot.

My question is, 15 rounds isn't going to cut it unless my computer really is just super slow, and the average server can hash 15 rounds in less than 10 seconds, and 1 is supposedly not secure at all, what is the best amount of rounds to hash?

I'm using bcryptjs which may not be helping with the speeds - being javascript.

Tobiq
  • 129
  • 1
  • 3
  • 6
    1 is pretty garbage. You'll be safe with 10-12. – d0nut Oct 10 '16 at 05:11
  • 1
    Slowing is the point. Number depends on risk, resources (server and app device) and application: Free game? Password manager? Store with 1-click purchase? Slow one time _sign-up_ is much more acceptable than slow _sign-in_, but both are preferable to a breach. How secure is your password (user, salt, hash) file? Really? – BillR Oct 10 '16 at 06:38
  • Are you running both sides on your (single) computer during development? – BillR Oct 10 '16 at 06:46
  • @BillR Yes, is that bad? – Tobiq Oct 10 '16 at 07:39
  • Similar question & answer here: http://security.stackexchange.com/questions/16318/how-should-i-choose-a-difficulty-factor-for-my-password-hashing-function Short answer: make it as slow as your users can tolerate (probably 0.5 - 1 second). – PwdRsch Oct 10 '16 at 17:58
  • @Tobiq Just trying to clarify what/where you are measuring that takes 5-10 sec. Execution in intended environment matters. My question was incomplete. O'Neil and others have provided you with guidelines (that will conflict on low-end/overcapacity hardware) but you have to balance value of data (e.g., $, politics, brag), user patience, target hardware capability, and organizational constraints (e.g., regulation? liability? reputation risk?). Also see https://security.stackexchange.com/questions/42238/how-can-i-make-sure-password-hashing-is-secure-on-computers-while-not-being-proh?rq=1 – BillR Oct 10 '16 at 21:40
  • In that question he speaks about the client hashing their password and Theen sending to the server, I thought the password was to be sent raw to the server and then had to be specially compared? – Tobiq Oct 10 '16 at 22:41

1 Answers1

4

Do you mean 6 rounds, or cost 6? Because cost 6 is 2^6 = 64 rounds.

Nowadays cost 10-12 is considered the minimum. However you need to look the maximum your hardware can handle.

The process of hashing should take approximetaly one second.

O'Niel
  • 2,740
  • 3
  • 17
  • 28