[wildfly-dev] On the WildFly Elytron PasswordFactory API

Anil Saldhana Anil.Saldhana at redhat.com
Thu Jun 12 11:55:10 EDT 2014


I also want to highlight the difference between PBE and PBKDF2 
(http://en.wikipedia.org/wiki/PBKDF2).
Developers keep pushing for PBKDF2 which is essentially a one way 
process. You cannot get the password back.
In the case of an application server, there is a need to get access to 
the configured database password to talk to
a database or another EIS system. So it is a two way process.  Not all 
databases can do a hashed/digest mechanism.

I hope we can document this in Elytron documentation somewhere.

Similarly, bcrypt (http://en.wikipedia.org/wiki/Bcrypt) is mentioned a 
lot. It again is a one way process.

Also below....

On 06/11/2014 11:14 AM, David M. Lloyd wrote:
> 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.
>
Agree. From Elytron perspective, it is important to provide the 
configuration to handle
all potential use cases.



More information about the wildfly-dev mailing list