title: Is it safe to increase BCrypt logrounds for a live Grails application using Spring Security without re-encoding all passwords?
body: <p>This question is for a production Grails app using Spring Security configured with BCrypt.</p>
  
  <p>To keep up with increasing server CPU speed, I would like to up the value of the <code>grails.plugin.springsecurity.password.bcrypt.logrounds</code> property so that password hashing takes longer and is less susceptible to attack.</p>
  
  <p>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).</p>
  
  <p>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</p>
  
  <p><code>$2a$10$i/PEPcvSj...</code> &lt;-- account created when logrounds was set to 10</p>
  
  <p><code>'$2a$20$3GGujw6o...</code> &lt;-- account created when logrounds was set to 20</p>
  
  <p>I have tested:</p>
  
  <ul>
  <li>Old accounts created before the change can still log in.</li>
  <li>Old accounts can change their password, and the new hashes use the new <code>logrounds</code> setting</li>
  <li>New accounts can be created and logged in as expected</li>
  <li>Trying to log in with an account that does not exist takes the expected new delay.</li>
  </ul>
  
  <p>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</p>