You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Paul Holding <pa...@pholding.co.uk> on 2012/09/21 18:04:02 UTC
Migrating from HashedCredentialMatcher to PasswordMatcher
I have a custom JDBC realm that is used to retrieve the user’s salt,
password, hash algorithm name and number of hash iterations from the
database which are all stored as separate columns.
I have this working correctly with the HashedCredentialMatcher but I would
like to now use the PasswordMatcher instead. The problem is when using the
PasswordMatcher, the passwords no longer match. Having stepped through the
code a few times I think the problem is the salt isn’t being used to hash
the password entered by the user, but I’m not 100% sure.
The following code uses the HashedCredentialMatcher and works correctly.
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken
token) throws AuthenticationException {
...
SimpleAuthenticationInfo info = new SimpleAuthenticationInfo(username,
passwdSalt.password, getName());
info.setCredentialsSalt(new SimpleByteSource(passwdSalt.salt));
HashedCredentialsMatcher hcm = new HashedCredentialsMatcher();
hcm.setHashAlgorithmName(passwdSalt.hashAlgorithmName);
hcm.setHashIterations(passwdSalt.hashIterations);
hcm.setStoredCredentialsHexEncoded(false);
setCredentialsMatcher(hcm);
return info;
}
The following code uses the PasswordMatcher and is what I intend to replace
the above code with however it doesn’t work
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken
token) throws AuthenticationException {
...
SimpleAuthenticationInfo info = new SimpleAuthenticationInfo(username,
passwdSalt.password, getName());
info.setCredentialsSalt(new SimpleByteSource(passwdSalt.salt));
DefaultPasswordService passwordService = new DefaultPasswordService();
DefaultHashService hashService = new DefaultHashService();
PasswordMatcher passwordMatcher = new PasswordMatcher();
hashService.setHashAlgorithmName(passwdSalt.hashAlgorithmName);
hashService.setHashIterations(passwdSalt.hashIterations);
passwordService.setHashService(hashService);
passwordMatcher.setPasswordService(passwordService);
setCredentialsMatcher(passwordMatcher);
return info;
}
I seem to recall reading somewhere that info.setCredentialsSalt is only used
with the HashedCredentialsMatcher but I’m unsure if this is true and if so
what should be used as a replacement when using the PasswordMatcher.
Any help on this would be much appreciated.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Migrating-from-HashedCredentialMatcher-to-PasswordMatcher-tp7577808.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Migrating from HashedCredentialMatcher to PasswordMatcher
Posted by Les Hazlewood <lh...@apache.org>.
Hi Paul,
The PasswordMatcher by default does not look at anything in the
AuthenticationInfo other than authenticationInfo.getCredentials(). This is
because it is expected that, when using the PasswordService, the
credentials object is a Modular Crypt Format [1] String that has the salt
(and any other necessary data) embedded in the String.
Because of this assumption (that everything necessary is part of a
MCF-formatted string that can be parsed for the relevant data), the
implementation does not check for any properties other than just
authcInfo.getCredentials();
As a bridge approach, you can subclass PasswordMatcher and override the
getStoredPassword(AuthenticationInfo info) method. In there, you can check
to see if the instance is a SaltedAuthenticationInfo instance, and if so,
inspect the properties to build and return, say, a Shiro1 MCF-formatted
String [2]. The rest of the logic downstream will work as if the stored
data was the expected MCF string.
Another approach is to do this same logic inside your Realm for only those
accounts that don't yet have a single MCF-formatted property.
Does that help?
[1] http://packages.python.org/passlib/modular_crypt_format.html
[2]
http://shiro.apache.org/static/current/apidocs/org/apache/shiro/crypto/hash/format/Shiro1CryptFormat.html
Cheers,
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
On Thu, Oct 4, 2012 at 2:11 PM, Les Hazlewood <lh...@apache.org> wrote:
> I'll take a look into it and get back shortly.
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
>
> On Thu, Oct 4, 2012 at 9:37 AM, Jared Bunting <jared.bunting@peachjean.com
> > wrote:
>
>> So, DefaultPasswordService is intended to be used with hashed passwords
>> generated by SimpleHash. If you run a password through this, you will
>> see that it actually embeds all the information necessary for
>> PasswordService in the output string. So, my recommendation is to not
>> try and store the salt separately, and just let shiro handle it.
>> Sorry that I can't provide more information on why your specific case
>> isn't working, but I'd have to dig into it a bit and the day job is
>> rather hectic right now.
>>
>> -Jared
>>
>> On Thu 04 Oct 2012 11:00:55 AM CDT, Paul Holding wrote:
>> > Sorry to keep going on about this but is anyone able to confirm whether
>> the
>> > setCredentialsSalt method in SimpleAuthenticationInfo is the correct
>> way to
>> > set the user's salt in a custom realm when using the PasswordMatcher?
>> If not
>> > is there another way I should be doing it?
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://shiro-user.582556.n2.nabble.com/Migrating-from-HashedCredentialMatcher-to-PasswordMatcher-tp7577808p7577834.html
>> > Sent from the Shiro User mailing list archive at Nabble.com.
>>
>>
>>
>
Re: Migrating from HashedCredentialMatcher to PasswordMatcher
Posted by Les Hazlewood <lh...@apache.org>.
I'll take a look into it and get back shortly.
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
On Thu, Oct 4, 2012 at 9:37 AM, Jared Bunting
<ja...@peachjean.com>wrote:
> So, DefaultPasswordService is intended to be used with hashed passwords
> generated by SimpleHash. If you run a password through this, you will
> see that it actually embeds all the information necessary for
> PasswordService in the output string. So, my recommendation is to not
> try and store the salt separately, and just let shiro handle it.
> Sorry that I can't provide more information on why your specific case
> isn't working, but I'd have to dig into it a bit and the day job is
> rather hectic right now.
>
> -Jared
>
> On Thu 04 Oct 2012 11:00:55 AM CDT, Paul Holding wrote:
> > Sorry to keep going on about this but is anyone able to confirm whether
> the
> > setCredentialsSalt method in SimpleAuthenticationInfo is the correct way
> to
> > set the user's salt in a custom realm when using the PasswordMatcher? If
> not
> > is there another way I should be doing it?
> >
> >
> >
> > --
> > View this message in context:
> http://shiro-user.582556.n2.nabble.com/Migrating-from-HashedCredentialMatcher-to-PasswordMatcher-tp7577808p7577834.html
> > Sent from the Shiro User mailing list archive at Nabble.com.
>
>
>
Re: Migrating from HashedCredentialMatcher to PasswordMatcher
Posted by Jared Bunting <ja...@peachjean.com>.
So, DefaultPasswordService is intended to be used with hashed passwords
generated by SimpleHash. If you run a password through this, you will
see that it actually embeds all the information necessary for
PasswordService in the output string. So, my recommendation is to not
try and store the salt separately, and just let shiro handle it.
Sorry that I can't provide more information on why your specific case
isn't working, but I'd have to dig into it a bit and the day job is
rather hectic right now.
-Jared
On Thu 04 Oct 2012 11:00:55 AM CDT, Paul Holding wrote:
> Sorry to keep going on about this but is anyone able to confirm whether the
> setCredentialsSalt method in SimpleAuthenticationInfo is the correct way to
> set the user's salt in a custom realm when using the PasswordMatcher? If not
> is there another way I should be doing it?
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Migrating-from-HashedCredentialMatcher-to-PasswordMatcher-tp7577808p7577834.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Re: Migrating from HashedCredentialMatcher to PasswordMatcher
Posted by Paul Holding <pa...@pholding.co.uk>.
Sorry to keep going on about this but is anyone able to confirm whether the
setCredentialsSalt method in SimpleAuthenticationInfo is the correct way to
set the user's salt in a custom realm when using the PasswordMatcher? If not
is there another way I should be doing it?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Migrating-from-HashedCredentialMatcher-to-PasswordMatcher-tp7577808p7577834.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Migrating from HashedCredentialMatcher to PasswordMatcher
Posted by Paul Holding <pa...@pholding.co.uk>.
I've done some further investigation and have stepped through the code
several times and I'm sure the problem is due to the salt not being used
when hashing the password entered by the user.
Whilst stepping through the code I've spotted the following.....
In DefaultPasswordService.java when the method passwordsMatch(Object
submittedPlaintext, String saved) is called on line 160 the object named
request contains the following
algorithmName=null
iterations=0
salt=null
source=cGFzc3dvcmQ=
The next line of code on line 161 calls computeHash(request)
In DefaultHashService.java when the method computeHash(HashRequest request)
is called, on lines 155 and 157 the variables algorithmName and iterations
are correctly set to "SHA-256" and 1 respectively. On line 159 the method
getPublicSalt(request) is called however it retuns null.
What I still don't understand is whether the object named request should
already contain the algorithmName, iterations and salt and if so, when/where
they should be set.
Could someone please help by pointing me in the right direction or suggest
how the salt should be set.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Migrating-from-HashedCredentialMatcher-to-PasswordMatcher-tp7577808p7577809.html
Sent from the Shiro User mailing list archive at Nabble.com.