Salted passwords have come up on cas-user a number of times over the
past several years and it seems like now is a good time to consider
adding support in the scope of authn API changes. Unfortunately there
are few standards for salted hashing where the authentication pipeline
would need to perform the encoding. For quasi standards like OpenLDAP
SSHA [1], for example, the cleartext password is provided on a simple
bind and the encoding happens server side.
Beyond the standards problem, there is the matter of following best
practices where each password is salted with a unique value. Some
systems generate random salts and store them, others derive the salt
from an attribute of the user account record (e.g. taking some bytes
from the hashed account creation time). From a design perspective we
would need a strategy pattern that allowed a fair bit of flexibility to
accommodate variable salt values. The high variance and absence of
standards pretty much guarantees that we can't provide anything out of
the box. It also makes it difficult to design the inputs into the
strategy, but the following would support both cases I mentioned
assuming there would be a lookup on username to get the (derived) salt:
interface PasswordSaltStrategy {
byte[] lookup(UsernamePasswordCredential credential);
}
Unfortunately there's an additional complication of how the salt is
joined with the password in computing the hash. Some methods prepend the
salt and others append it; there may be other approaches.
With all the variation and lack of standards this looks difficult. Are
there any concrete requirements to drive this feature? I recall general
requests for "salted passwords," but I can't find any specific requests
or citations of standards.
M
[1] http://www.openldap.org/faq/data/cache/347.html
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
