dhis2-devs team mailing list archive

[Halvdan Grelland <halvdanhg@xxxxxxxxx>]

Thanks!

Indeed. As I'm sure you know bCrypt hashes embed the salt within the stored
string. As you say this is great news for anyone interested in integration
with external systems or code bases.
Also, the cost factor (round count exponent) is given for each hash, making
it easy and seamless to 'upgrade' security if needed in the future.

For now we are using the default cost factor of 10, by the way (2^10
rounds). Some would probably argue that this is insufficient, so we might
consider raising it sometime soon. Any input in regards to this is
appreciated!

It's been well tested but given the security critical nature of the changes
I encourage everyone to inspect and test the code if interested. I
appreciate any feedback! A good mantra for security is to realise there can
and will *always* be flaws.

Halvdan

2014-09-30 17:25 GMT+02:00 Bob Jolliffe <bobjolliffe@xxxxxxxxx>:

> Halvdan this looks excellent.  Computing a straight bcrypt hash is so much
> stronger than the peculiar messy business which ended up in an md5 hash of
> a weird java string hash.
>
> This should also make it easier for those who have an interest in
> generating password hashes outside of dhis - eg using python, R or what
> have you.  I see the algoritihm for generating the hash is pretty standard
> -
> https://github.com/spring-projects/spring-security/blob/master/crypto/src/main/java/org/springframework/security/crypto/bcrypt/BCryptPasswordEncoder.java
> .  - thats a challenge to Jason to create a R version :-)
>
> Its really great to say the effort you have gone to migrating from the old
> hashes.  Lets hope it works - I presume you have tested well :-)
>
> Cheers
> Bob
>
> On 30 September 2014 15:37, Halvdan Grelland <halvdanhg@xxxxxxxxx> wrote:
>
>> Hi devs,
>>
>> Starting from trunk rev. 16881 (2.17 snapshot) we've made some major
>> changes to the password handling scheme of DHIS 2. In short: all passwords
>> and restore tokens are now stored as bcrypt hashes with random salts. This
>> gives a great boost to security, but might carry some challenges for
>> developers.
>>
>> All existing users in the DB are now being migrated to bcrypt hashes *on
>> login*. In production this should work smoothly. However in a
>> development context you might encounter the following situation:
>>
>>  - Logging in with any user on DHIS rev >= 16881 will change the password
>> hash to the new scheme.
>>  - A development branch which has not been merged with DHIS rev > 16881
>> yet will then fail to authenticate the same user (both branches run on the
>> same dev db) as the hash is not a valid MD5 digest anymore.
>>
>> I strongly suggest you merge any active development branches with trunk
>> ASAP to avoid this conflict. You could also run any older branches on a
>> different database (the provided sample data has not yet been altered to
>> reflect the new scheme).
>>
>> Feel free to email me if you have any questions.
>>
>> Halvdan Grelland
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>