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).
On Tue, Sep 30, 2014 at 10:37 AM, Halvdan Grelland halvdanhg@gmail.com 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).
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.
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).
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 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.
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).
I don’t think this work will have any effect on the way basic authentication works.
What has changed is the algorithm used to calculate the hash of the password (the ‘encrypted’ form) which is saved in the database. What we have been using before is now quite old and not considered very robust.
Does this mean that the authorization header (basic authentication) in the web api will also change? If yes, could you please point us to some tutorial which will help us to come up with the authorization header?
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 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.
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).
I don’t think this work will have any effect on the way basic authentication works.
What has changed is the algorithm used to calculate the hash of the password (the ‘encrypted’ form) which is saved in the database. What we have been using before is now quite old and not considered very robust.
Does this mean that the authorization header (basic authentication) in the web api will also change? If yes, could you please point us to some tutorial which will help us to come up with the authorization header?
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 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.
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).
