Mark, On 9/16/14 12:46 PM, Mark Thomas wrote: > 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.
The "matches" method should not have to call the public one-arg "mutate" and should therefore not need the salt at all: it will unpack the stored credential which contains the salt and iteration count. The salt and iteration count is only required when generating a /new/ password to be stored. Otherwise, all that information it packed into the existing (stored) credential and can be checked. Specifying the salt size and iteration count in the configuration will only affect credentials that are created /after/ that node is launched. Any credentials created in the past will use whatever salt length and iteration count that were used when the credential was created. I see you have written a number of responses. I'll try to consolidate my responses to those instead of replying individually. -chris
signature.asc
Description: OpenPGP digital signature
