Seems like a feature that can be deferred, affording time and experience to shake out the design in a feature branch or forked repo or extension module before drawing it in stable and baked to a future CAS release, no?
I agree support for salting has promise; I'm having trouble seeing now as a good moment to go after this in cas-server itself. cas-addons has some salting support. It's not baked enough (static salt is not sufficient) and so I don't suggest drawing that into cas-server itself at this time. Were it more successfully baked, I'd be suggesting that. https://github.com/Unicon/cas-addons/blob/master/src/main/java/net/unicon/cas/addons/authentication/handler/ShiroHashServicePasswordEncoder.java Perhaps the next thing to do to that code is to enable dynamic salt (i.e., the username) rather than a static salt. Andrew On Fri, Jun 7, 2013 at 5:46 AM, Marvin S. Addison <[email protected]>wrote: > 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<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<http://www.ja-sig.org/wiki/display/JSG/cas-dev> > -- 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
