Archive for December, 2013

Automatically converting password hashes in Grails spring-security-core

Friday, December 20th, 2013

I was looking at this Stack Overflow question about converting password hashes and realized that it’s possible and rather convenient when using the spring-security-core plugin to automate the process.

To start, we’ll need a PasswordEncoder that can work with both algorithms. Here I’m assuming that you’ll be converting from SHA-256 (optionally with a salt) to bcrypt, but the general approach is mostly independent of the algorithms. Sha256ToBCryptPasswordEncoder will always hash new passwords using bcrypt, but can detect the difference between hashes from SHA-256 and bcrypt in isPasswordValid:


import grails.plugin.springsecurity.authentication.encoding.BCryptPasswordEncoder;


public class Sha256ToBCryptPasswordEncoder
       implements {

   protected MessageDigestPasswordEncoder sha256PasswordEncoder;
   protected BCryptPasswordEncoder bcryptPasswordEncoder;

   public String encodePassword(String rawPass, Object salt) {
      return bcryptPasswordEncoder.encodePassword(rawPass, null);

   public boolean isPasswordValid(String encPass,
            String rawPass, Object salt) {
      if (encPass.startsWith("$2a$10$") && encPass.length() == 60) {
         // already bcrypt
         return bcryptPasswordEncoder.isPasswordValid(
                    encPass, rawPass, null);

      if (encPass.length() == 64) {
         return sha256PasswordEncoder.isPasswordValid(
                    encPass, rawPass, salt);

      // TODO
      return false;

    * Dependency injection for the bcrypt password encoder
    * @param encoder the encoder
   public void setBcryptPasswordEncoder(BCryptPasswordEncoder encoder) {
      bcryptPasswordEncoder = encoder;

    * Dependency injection for the SHA-256 password encoder
    * @param encoder the encoder
   public void setSha256PasswordEncoder(
           MessageDigestPasswordEncoder encoder) {
      sha256PasswordEncoder = encoder;

This needs dependency injections for properly configured SHA-256 and bcrypt encoders, and we’ll see that in a bit.

Sha256ToBCryptPasswordEncoder cannot make any changes as only password information is available, so we’ll subclass DaoAuthenticationProvider and do this work in additionalAuthenticationChecks:


import grails.plugin.springsecurity.SpringSecurityUtils
import grails.plugin.springsecurity.userdetails.GrailsUser


class PasswordFixingDaoAuthenticationProvider
extends DaoAuthenticationProvider {

   def grailsApplication

   protected void additionalAuthenticationChecks(
         UserDetails userDetails,
         UsernamePasswordAuthenticationToken authentication)
            throws AuthenticationException {
      super.additionalAuthenticationChecks userDetails, authentication

      // if we got this far the password was ok

      String oldHashedPassword = userDetails.getPassword()
      if (oldHashedPassword.startsWith('$2a$10$') &&
            oldHashedPassword.length() == 60) {
         // already bcrypt

      if (oldHashedPassword.length() != 64) {
         // TODO

      String bcryptPassword = getPasswordEncoder().encodePassword(
               authentication.credentials, null) 

      // use HQL to update the password in the database directly

      def conf = SpringSecurityUtils.securityConfig
      String userClassName = conf.userLookup.userDomainClassName
      Class<?> User = grailsApplication.getDomainClass(userClassName).clazz

      def args = [p: bcryptPassword]
      String hql = 'update ' + + ' u set u.password=:p where '
      if (userDetails instanceof GrailsUser) {
         hql += '' =
      else {
         hql += 'u.' + conf.userLookup.usernamePropertyName + '=:un'
         args.un = userDetails.username

      User.withNewSession {
         User.withTransaction {
            User.executeUpdate hql, args

Calling super.additionalAuthenticationChecks() will ensure that a password was provided and it will be verified using either SHA-256 or bcrypt by Sha256ToBCryptPasswordEncoder, so if there is no exception thrown it’s safe to update the password. Note that the update code is generic and can be made more compact by hard-coding your class and property names.

We register Sha256ToBCryptPasswordEncoder as the passwordEncoder bean, and create bcryptPasswordEncoder and sha256PasswordEncoder beans, configured with the SHA-256 settings that were being used, and the bcrypt settings that will be used (configure those in Config.groovy as described in the docs). Also configure the bean override of daoAuthenticationProvider to be a PasswordFixingDaoAuthenticationProvider with the same configuration as is done in SpringSecurityCoreGrailsPlugin.groovy with the addition of the grailsApplication reference:

import grails.plugin.springsecurity.SpringSecurityUtils
import grails.plugin.springsecurity.authentication.encoding.BCryptPasswordEncoder



beans = {

   def conf = SpringSecurityUtils.securityConfig

   bcryptPasswordEncoder(BCryptPasswordEncoder, conf.password.bcrypt.logrounds) // 10

   sha256PasswordEncoder(MessageDigestPasswordEncoder, conf.password.algorithm) {
      encodeHashAsBase64 = conf.password.encodeHashAsBase64 // false
      iterations = conf.password.hash.iterations // 10000

   passwordEncoder(Sha256ToBCryptPasswordEncoder) {
      bcryptPasswordEncoder = ref('bcryptPasswordEncoder')
      sha256PasswordEncoder = ref('sha256PasswordEncoder')

   daoAuthenticationProvider(PasswordFixingDaoAuthenticationProvider) {
      userDetailsService = ref('userDetailsService')
      passwordEncoder = ref('passwordEncoder')
      userCache = ref('userCache')
      saltSource = ref('saltSource')
      preAuthenticationChecks = ref('preAuthenticationChecks')
      postAuthenticationChecks = ref('postAuthenticationChecks')
      authoritiesMapper = ref('authoritiesMapper')
      hideUserNotFoundExceptions = conf.dao.hideUserNotFoundExceptions // true
      grailsApplication = ref('grailsApplication')

With this configuration, new users’ passwords will be hashed with bcrypt, and valid existing users’ passwords will be converted to bcrypt using the plaintext passwords used during login. Once your users are converted, back out these changes and convert to the standard bcrypt approach. This would involve deleting the grails.plugin.springsecurity.password.algorithm attribute and all salt configuration since bcrypt doesn’t support a salt, deleting Sha256ToBCryptPasswordEncoder and PasswordFixingDaoAuthenticationProvider, and removing the bcryptPasswordEncoder and sha256PasswordEncoder bean definitions and passwordEncoder and daoAuthenticationProvider overrides from resources.groovy since the beans configured by the plugin using Config.groovy settings will be sufficient. Also if you had added salt to the User class encodePassword method, e.g.

protected void encodePassword() {
   password = springSecurityService.encodePassword(password, username)

convert it back to the default without a salt:

protected void encodePassword() {
   password = springSecurityService.encodePassword(password)

Some approaches for diagnosing spring-security-core login errors

Wednesday, December 11th, 2013

If you use the Grails spring-security-core plugin and you’re unable to authenticate, it can be hard to know where to start looking for the cause. Often it’s due to confusion from older blog posts that tell you to explicitly hash the password when creating a user, e.g.

def user = new User(username: 'me', enabled: true,
     password: springSecurityService.encodePassword('password')).save()

But the generated User domain class auto-hashes your password for you, so you would just do this (I omitted setting enabled since in 2.0 it defaults to true):

def user = new User(username: 'me', password: 'password').save()

If that isn’t the problem, Spring Security logs a lot at the debug level, so enable that in the log4j block in Config.groovy:

log4j = {
   debug ''

With any luck there will be a useful signal in the noise and it’ll point you in the right direction.

If that doesn’t do it, you can configure a debugger and set a breakpoint in in the authenticate method. That’s where each registered AuthenticationProvider gets a chance to attempt an authentication if it supports the current Authentication.

Not everyone likes to use a debugger though. Another option is to register an event listener and look at the failure events. This is described in the plugin docs here. Here’s a simple configuration that will print information to the console for all failure events:

grails.plugin.springsecurity.useSecurityEventListener = true
grails.plugin.springsecurity.onAbstractAuthenticationFailureEvent = { e, appCtx ->
   println "\nERROR auth failed for user $ $e.exception.message\n"

Using MongoDB With Version 2.x of the Grails Spring Security Core Plugin

Sunday, December 01st, 2013

With a few customization steps it’s easy to use MongoDB to store user and role information for the spring-security-core plugin instead of using Hibernate, and after seeing this Stack Overflow question I thought I’d write up some notes on how to do this with the current plugins. Note that much of this is based on this blog post.

I created a demo application using Grails 2.3.3; it’s available on GitHub. The general steps were:

  • $ grails create-app mongoSpringSecurity
  • add the plugins to BuildConfig.groovy
  • $ grails s2-quickstart auth User Role
  • update DataSource.groovy to use MongoDB
  • create a custom UserDetailsService and register it in resources.groovy
  • create a test role and a user in BootStrap.groovy
  • customize the domain classes to use MongoDB
  • add tags to index.gsp to add a login link if you’re not logged in, and show that you’re logged in if you are

One difference between what I do here and what was done in the original blog post is that the custom UserDetailsService is not a Grails service – it’s in src/groovy and not in grails-app/services. It wasn’t necessary to be a real service then and isn’t now; it’s a coincidence that the Spring Security interface name ends in “Service”. See the plugin documentation for general information about customizing this bean.

You can see the source for the custom bean here. By embedding the authorities in the user domain class, the many-to-many relationship is not needed and the model is a lot simpler, so the class implementation is also – for example there’s no need for a withTransaction block to avoid lazy loading exceptions.

The changes for the User class are fairly minor. You need static mapWith = 'mongo' if you have both the Hibernate and MongoDB plugins; in this case it’s unnecessary but harmless to leave it in. The id field should be an ObjectId, and I retained the other customizations from the earlier blog post (the embedded roles, the addition of the email field, extra constraints, etc.). The Role class changes are similar.

Since we’re using a custom UserDetailsService, we can delete the userLookup.userDomainClassName, userLookup.authorityJoinClassName, and authority.className properties from Config.groovy, and since the roles are embedded in the user class we can delete the generated UserRole class.

You should be able to clone the repo and start the application (assuming you have MongoDB and Grails 2.3.3 already). Click the login link on the start page and after you successfully authenticate, the link should be replaced by a message.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.