Hi Peter, Prior to 1.1, salts were usually obtained from the submitted AuthenticationToken, which can be a security risk (relying on end-user submitted data for salts is not safe, as this can be exploited by attackers). The now-deprecated 'hashSalted = true' configuration line told Shiro to acquire the salt from the submitted AuthenticationToken, which is less than ideal.
Salts should instead always be acquired based on the stored AuthenticationInfo, since this is considered 'safe' and not end-user dependent. The way to do this is to return instances of SaltedAuthenticationInfo (which is implemented by default by SimpleAuthenticationInfo). Naturally the SaltedAuthenticationInfo instance must return a non-null value for the getCredentialsSalt() call. If it returns null, then no salting will be performed. In Göran's first example, it was acquiring the salt based on the AuthenticationToken. In his second example, he is doing it the recommended way to ensure the salt value is based on something only the server knows. It is also important to note, that if any salts are still based on usernames (or other user-entered data), it is highly recommended to change the salts ASAP to be based on, say, randomly generated numbers. The Realm documentation page shows code examples of how to do this easily using Shiro's RandomNumberGenerator concept in the "Hashing and Corresponding Matchers" section: http://shiro.apache.org/realm.html Also note that the The HashedCredentialsMatcher JavaDoc covers the backwards-compatibility notes (and why the technique was changed) in detail: http://shiro.apache.org/static/current/apidocs/org/apache/shiro/authc/credential/HashedCredentialsMatcher.html I hope this sheds some clarity! Best, -- Les Hazlewood Founder, Katasoft, Inc. Application Security Products & Professional Apache Shiro Support and Training: http://www.katasoft.com On Thu, Feb 10, 2011 at 7:25 AM, Peter Ledbrook <[email protected]> wrote: > Hi, > > Someone had a problem upgrading from version 1.0.1 of the Grails > plugin to 1.1.3 (see below). This is basically an upgrade from Shiro > 1.0 to 1.1. Any idea what refactoring may have changed the behaviour > of SimpleAccount with salted passwords? I ask because I may need to > update the plugin and/or add a warning to the release notes. > > Thanks, > > Peter > > > ---------- Forwarded message ---------- > From: Goran Ehrsson <[email protected]> > Date: 9 February 2011 21:14 > Subject: Re: [grails-user] Upgraded shiro plugin from 1.0.1 to 1.1.3 > -> login failed - salt issue > To: [email protected] > > > I did not change encryption algorithm, I have used Sha512 all the > time. Both with shiro 1.0.1 plugin and now with 1.1.3. > > credentialMatcher(org.apache.shiro.authc.credential.Sha512CredentialsMatcher) > { > storedCredentialsHexEncoded = true > hashSalted = true > hashIterations = n > } > > /Göran > > > Scott Ryan wrote 2011-02-09 22:02: >> >> They changed the encryption algorithm between versions did you rehash all >> your passwords? >> >> Scott Ryan >> On Feb 9, 2011, at 1:07 PM, Goran Ehrsson wrote: >> >>> Hi, >>> >>> I upgraded my shiro plugin from 1.0.1 to 1.1.3 today. >>> I changed package names for SavedRequest and WebUtils as documented in >>> http://grails.org/Shiro+Release+Notes >>> Started the application and tried to login... Invalid password! >>> I reverted back to 1.0.1 and could login successfully again. >>> So I started to investigate (AuthController, Realm, Filters, >>> resources.groovy, etc.) but could not find any unusual differences. >>> Then just by change I changed the constructor for SimpleAccount in my >>> DbRealm to include the salt since my password was salted. And voila! I >>> could login. >>> >>> I'm happy but confused... >>> >>> My working 1.0.1 ShiroDbRealm.groovy: >>> def account = new SimpleAccount(username, user.passwordHash, "ShiroDbRealm") >>> >>> My working 1.1.3 ShiroDbRealm.groovy: >>> def account = new SimpleAccount(username, user.passwordHash, new >>> org.apache.shiro.util.SimpleByteSource(salt.bytes), "ShiroDbRealm") >>> if (!credentialMatcher.doCredentialsMatch(authToken, account)) { >>> throw new IncorrectCredentialsException("Invalid password for user >>> '${username}'") >>> } >>> >>> What have changed that caused this? I'm curious. >>> >>> /Göran Ehrsson > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > > > -- > Peter Ledbrook > Grails Advocate > SpringSource - A Division of VMware
