On 16/09/2014 17:17, Mark Thomas wrote: > On 16/09/2014 16:20, Christopher Schultz wrote:
>> 2. I don't like CredentialHandler.mutate(String input, byte[] salt, int >> iterations). I think it ties the method signature to the implementation >> of the mutation algorithm. PBKDF2 for instance has both "salt" and >> "iterations", but straight-up MD5 (e.g. our existing implementation) >> does not. Also, non-hashing algorithms like any symmetric encryption >> algorithm (e.g. AES, Blowfish, etc.) does not have such parameters, and >> would require instead an encryption key. I think that mutate() should >> only take a single argument but also have setters that can be called >> from configuration, like this: >> >> <Realm> >> <CredentialHandler class="PBKDF2" saltSize="8" iterations="50000" /> >> </Realm> >> >> In this case, the PBKDF2 class would have a setIterations(int) method >> and a setSaltSize(int) method to set the number of salt bytes to use. >> >> If we want the implementations for MessageDigest-based handlers as well >> as things like PBKDF2 to extend the same base class that provides lots >> of utility methods, that's find. I just don't like tying the interface >> itself for the matches() method to a particular style of implementation. > > I take the point but having fixed values for saltSize and iterations > then limits you to using the same values for every entry in the Realm > which creates a different set of issues. I'm not sure there is an API > that can meet all those requirements but it is worth spending some time > thinking about it. Hmm. mutate() needs the actual salt, not the salt size, and that is going to be different for every entry. I don't see a viable option apart from passing it in as a parameter that doesn't involve some form of ugly hack that defeats the benefit of a single parameter mutate method. I have some ideas for handling a variety of salt sizes and iteration counts but I don't yet see a way around mutate() needing the actual salt. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
