(Being a committer, it may sound a bit odd I say this but...) yeah,
I've wondered about this too. As you mentioned, out of the box, the
API supports deriving salt from an AuthenticationToken (you can argue
about the effectiveness). As stated in
http://incubator.apache.org/shiro/static/current/apidocs/org/apache/shiro/authc/credential/HashedCredentialsMatcher.html#getSalt(org.apache.shiro.authc.AuthenticationToken):
"This default implementation merely returns token.getPrincipal(),
effectively using the user's identity (username, user id, etc) as the
salt, a most common technique. If you wish to provide the
authentication token's salt another way, you may override this method.
"
Most common or not but if you bother to salt the password why not do
it properly. For Xnix-style, fixed-width, per-password random salt,
you need to implement your own CredentialsMatcher and an additional
encode() operation somewhere (I keep mine with my custom
CredentialsMatcher out of convenience), something like this (for a
fixed-width salt):
public static String encode(String password, int saltWidth, int
hashIterations) {...}
that knows how to encode and prefix the salt to the encoded password.
Obviously, you also need something like:
protected String getSalt(AuthenticationInfo token) {...}
whereas the default operation simply does:
@Override
protected Object getSalt(AuthenticationToken token) {
return new NoSuchAlgorithmException("Cannot return salt without
authentication info");
}
After that, you simply to need to set the CredentialsMatcher to your
realm. The current CredentialsMatcher implementation is a bit
trigger-happy with inheritance... to me, a single CredentialsMatcher
with specific algorithm set as a property should have been enough to
cover the use cases for the existing classes and inheritance should be
reserved for denoting logically different behavior of the
CredentialsMatchers. Not that it would be too late to change that.
Feel free to open an issue (and add a patch!).
Kalle
On Wed, Sep 1, 2010 at 11:31 PM, Mike K <[email protected]> wrote:
>
> I am looking to use per-password salting using random numbers.
> Looking at the HashedCredentialsMatcher.getSalt it uses the
> AuthenticationToken (the user name) for salt.
> Any recommendations on how to extend the getSalt api in order to retrieve a
> salt stored with a DAO? It seems like the Realm would be the right place for
> this, but the current API does not seem to support something like that.
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Password-Salting-one-salt-per-password-tp5490030p5490030.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
