Re: Using HashedCredentialsMatcher and fixed-length, random salt

[Kalle Korhonen <ka...@gmail.com>]

(Moving out of dev list, probably more of a user thread)

I implemented a fixed-with, random salt credentials matcher but I'm not very
happy with the initial implementation. I partly blame the api that doesn't
seem to let you do this very easily, but I may be missing something that'd
make it easier. I'd be interested to hear if anybody has worked on this
before and have an implementation ready.

One of the issues is, as I mention below, that current signature for
HashedCredentialsMatcher.getSalt() doesn't work for random salt as far as I
can see. The second issue is that since the Hash is a wrapper around a byte
array that encompasses encoding, I cannot easily store a hex string
representation with a salt string added to it. Basically to get the salt
string in my custom getSalt(), I get the existing credentials, assume it's a
Hash, get the bytes and construct a string out of it which feels backwards
to me. I think partly the complexity is my own fault, I should just store
the byte array as is instead of trying to encode it into a string. Finally,
the matcher is just a matcher and not symmetric, i.e. it doesn't help you
hashing a clear-text password (I think there was another thread asking about
this a while ago). I have an earlier take on the same problem with Acegi (
https://svn.codehaus.org/trails/tags/trails-1.2.1/modules/trails-security/src/main/java/org/trails/security/password/DigestUtil.java)
and while not as generic as the jsec classes, it was a lot simpler to use.
So, basically I'd like to compare with any existing implementation and hear
any devs' thoughts of the best implementation strategy.

Kalle


On Fri, Feb 27, 2009 at 1:00 PM, Kalle Korhonen
<ka...@gmail.com>wrote:

> I didn't see any easy way of using a random salt (which I consider a common
> practice) with the existing hashed matchers. I can always override
> doCredentialsMatch() in my custom matcher but then the protected credentials
> getters are kind of pointless. Would it not make sense that
> getCredentials(AuthenticationToken) would also accept AuthenticationInfo as
> the second parameter? Then it could internally call (the currently
> non-existent) getSalt(AuthenticationInfo) if it so wishes. Or in fact, I'd
> just change the signature of getSalt to getSalt(Object) to make it work for
> all cases (static salt, user-specific static salt, random salt). The current
> signature seems to be geared towards implementing (user-specific but still)
> static salt. Furthermore, the current Matcher implementation looks a bit
> trigger-happy with inheritance. Shouldn't the digest algorithm being used
> just be a property of HashedCredentialsMatcher? There could/should be only
> two derived classes from it, StaticSaltCredentialsMatcher and
> FixedLengthSaltCredentialsMatcher, or what do you think? These changes could
> be added without any visible changes to users.
>
> Kalle
>