1

I've just started a Grails 2.4.4/Spring Security 2.0-RC4 (plugin) app. I'm using the same security configuration I have in Grails 2.3.11/Spring Security 1.2.7.3:

grails.plugin.springsecurity.password.algorithm = 'bcrypt'
grails.plugin.springsecurity.password.bcrypt.logrounds = 31

It hangs on startup - or so I thought. Really, it just starts to take an incredibly long time to start when log rounds is in the 20s. With the previous app, there is no delay when set to 31. After comparing the docs, I notice the 2.0 plugin has a new config option:

Property                    Default Description
password.hash.iterations    10000   the number of iterations which will be executed on the hashed password/salt.

I then dug into the code and it appears that 2.0 no longer relies on jbcrypt, but a Spring implementation (org.springframework.security.crypto.bcrypt).

I assume that has something to do with the difference in speed, but I don't understand bcrypt or the difference in implementation well enough to compare them. Can someone shed light on this? What would make them equivalent? And is that what I want, or is my older app insecure?

Philip
  • 697
  • 7
  • 20

1 Answers1

2

The password.hash.iterations option does not apply to bcrypt, but is to be used with other hash algorithms, like SHA-256.

Note that bcrypt logrounds is not the same as iterations. Number of iterations = 2log_rounds. Example: 12 logrounds = 4096 (212) iterations.

If the calculation goes fast, it is very likely not 31 bcrypt logrounds being applied.

Update: Old jbcrypt versions have an overflow bug where a setting of 31 causes zero (0) iterations instead of 231! The .NET port has suffered from the same problem.

Community
  • 1
  • 1
holmis83
  • 15,922
  • 5
  • 82
  • 83
  • Well, both are using bcrypt, but as mentioned the implementation changed from jbcrypt to Spring's implementation. For both versions of the plugin, the [docs](http://grails-plugins.github.io/grails-spring-security-core/guide/passwords.html) say "the number of rounds must be between 4 and 31." Given your explanation and the current behavior (which matches your expectation of 31 being very slow), I'm wondering if there's an issue with jbcrypt. Might explain the change. – Philip Feb 19 '15 at 05:27
  • I'm accepting your answer because it shed enough light for me to realize this is the wrong question. The right question is now, "Why does Grails Spring Security 1.2 bcrypt run so fast with log rounds = 31?" Thank you. – Philip Feb 19 '15 at 19:20
  • @Philip If you look at the generated hash, it can give a hint about how it actually was created. – holmis83 Feb 19 '15 at 20:05
  • In my 1.2 app, they look like: `$2a$31$A.BpHCgj9oSGahhlZJVbEumqILSWTl85J315H8JpxI6o/jt.87v6K` in 2.0, they look like: `$2a$12$Mg7Y/tHMgIpazjQKkHwFfu68VkgX8emoNgkla5mm0cKHcKx59SS3C` I note the number after the second $ matches the log rounds setting. It occurs to me that jbcrypt might just be orders of magnitude more efficient in its implementation vs. Spring's. – Philip Feb 20 '15 at 00:30