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.