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
