Scott M Stark wrote: >> >>I'll have a go at modifying UsernamePasswordLoginModule accordingly... >> > That's fine. This should be done using the java.security.MessageDigest class > so that additional one-way hash algorigthms may be introduced using > java.security.MessageDigestSpi subclasses. >
But isn't that part of the JCA* stuff - you should only have to specify an algorithm name to MessageDigest.getInstance, no? The Spi stuff is all hidden. If you want to make the algorithm completely pluggable (e.g. to use salting or some other guff to prevent dictionary attacks) then you would have to provide your own password hashing interface. This would also allow you to modify the way the hash string was formed for storing and comparing (base 64 etc). I was thinking of allowing either a hash algorithm to be specified as an option - SHA, MD5 whatever, with a default string format (hex), or a separate hash implementation class (or both). >> Do you >>think it would be worth changing AbstractSecurityProxy to make this the >>default in JBoss 3? >> >> > Sure. The behavior controlled by a flag that defaults to the case of not > allowing access to missing methods. > You mean a) check on each invocation and only crack up if a method is called which doesn't have a corresponding proxy method rather than b) check for all methods on initialization (when constructing the method maps) and throw an exception if the proxy doesn't match. Luke. * 'C' for cryptography not connector - I get confused when people start recycling acronyms... -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.mkeym.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
