Search code examples
grailsspring-securitybcrypt

Is it safe to increase BCrypt logrounds for a live Grails application using Spring Security without re-encoding all passwords?


This question is for a production Grails app using Spring Security configured with BCrypt.

To keep up with increasing server CPU speed, I would like to up the value of the grails.plugin.springsecurity.password.bcrypt.logrounds property so that password hashing takes longer and is less susceptible to attack.

At first thought, I figured this was a daunting task requiring a trickle approach as users logged in or massive re-encoding and custom login handlers, but it appears to work without any other change when trying it locally between runs (with a persistent database, simulating a non-local deploy).

I'm guessing this is because the logrounds is stored on the password hash: when going from 10 to 20 between runs locally, for example, the passwords look as follows

$2a$10$i/PEPcvSj... <-- account created when logrounds was set to 10

'$2a$20$3GGujw6o... <-- account created when logrounds was set to 20

I have tested:

  • Old accounts created before the change can still log in.
  • Old accounts can change their password, and the new hashes use the new logrounds setting
  • New accounts can be created and logged in as expected
  • Trying to log in with an account that does not exist takes the expected new delay.

Is there any reason not to proceed with the change? The high degree of caution here is because a mistake that prevents production login in any way would be extremely costly


Solution

  • Everything worked as expected, so the answer is that yes, you can. You can change the logrounds without impact to existing accounts as the logrounds used to produce the hash is built into the hash. Nice feature of BCrypt