[wildfly-dev] On the WildFly Elytron PasswordFactory API

[David M. Lloyd]

On 06/11/2014 10:44 AM, Bill Burke wrote:
>
>
> On 6/11/2014 11:33 AM, Anil Saldhana wrote:
>> On 06/11/2014 09:30 AM, David M. Lloyd wrote:
>>> On 06/04/2014 11:07 AM, David M. Lloyd wrote:
>>> [...]
>>>> Example: Encrypting a new password
>>>> ----------------------------------
>>>>
>>>>        PasswordFactory pf = PasswordFactory.getInstance("sha1crypt");
>>>>        // API not yet established but will be similar to this possibly:
>>>>        ???? parameters = new
>>>> ???SHA1CryptPasswordParameterSpec("p4ssw0rd".toCharArray());
>>>>        Password encrypted = pf.generatePassword(parameters);
>>>>        assert encrypted instanceof SHA1CryptPassword;
>>> I have a concrete specification for this example now:
>>>
>>>         PasswordFactory pf = PasswordFactory.getInstance("sha-256-crypt");
>>>         // use a 64-byte random salt; most algorithms support flexible sizes
>>>         byte[] salt = new byte[64];
>>>         ThreadLocalRandom.current().getBytes(salt);
>>>         // iteration count is 4096, can generally be more (or less)
>>>         AlgorithmParameterSpec aps =
>>>                 new HashedPasswordAlgorithmSpec(4096, salt);
>>>         char[] chars = "p4ssw0rd".toCharArray();
>>>         PasswordSpec spec = new EncryptablePasswordSpec(chars, aps);
>>>         Password pw = pf.generatePassword(spec);
>>>         assert pw.getAlgorithm().equals("sha-256-crypt");
>>>         assert pw instanceof UnixSHACryptPassword;
>>>         assert pf.verifyPassword(pw, chars);
>>>
>> - Best is to make the salt and iteration count configurable.
>
> +1
>
> 5000 iterations is actually a *huge* performance hit, but unfortunately
> way lower than what I've seen recommended.  (I've seen as high as
> 100,000 based on today's hardware).

Yeah the point of having the algorithm parameter spec is to allow these 
things to be specified.  Iteration count is recommended to be pretty 
high these days, unfortunately, but with this kind of parameter spec, it 
is completely configurable so if there's some reason to use a lower 
count (or a higher one), you can certainly do it.

> In Keycloak we store the iteration count along with the password so that
> the admin can change the default iteration count in the future.  We
> recalculate the hash on a successful login if the default count and user
> count are different.

Yeah the newer SASL SCRAM mechanisms (and other challenge-response 
mechanisms like Digest-MD5 and, I believe, HTTP's digest) also have some 
support for caching pre-hashed passwords to help performance.  While on 
the one hand, this means that the hash is essentially sufficient to 
authenticate, on the other hand the server can always periodically 
regenerate the hash with a different salt, which causes the previous 
hashed password to essentially become invalid without actually requiring 
a password change.

-- 
- DML