Password Hash

This Wiki is read-only for reference purposes to avoid broken links.

Status

in production use

Contributors

Adaxa Pty Ltd (Paul Bowden)

Overview

from ... http://sourceforge.net/p/adempiere/contributions/212/

User passwords should be stored in a non-recoverable form in case the database is compromised:

http://www.h-online.com/security/features/Storing-passwords-in-uncrackable-form-1255576.html

Adaxa has implemented password hashing based on the recommendations in

https://www.owasp.org/index.php/Hashing_Java

using a random salt and hashing with 1000 rounds of the SHA-512 algorithm.

Pushed to contribution_adaxa

http://adempiere.hg.sourceforge.net/hgweb/adempiere/contribution_adaxa/rev/6d9090d8a9f6

Testing and comments welcomed.

Notes: 1) added column "salt" to ad_user

2) increased length of ad_user.password to 1024 (see 5)

3) added/changed passwords will automatically be saved in hashed form

4) code will still authenticate plain-text/encrypted passwords

5) if password column is encrypted then stored hashes will be encrypted (redundant but the easiest way to achieve backwards compatibility)

6) Added process "Hash Passwords" to convert all existing user passwords -- backup first!

Functional team

• Volunteers for analyzing:
  • Mario Calderon 13:00, 24 June 2013 (UTC) - Functional Review

Result of review by Mario Calderon, June 24th, 2013

• Opened as SystemAdministrator the column AD_User
• Checked definition of Field Password:length is 1024 as described in https://sourceforge.net/p/adempiere/contributions/212/
• From a functional point of view, the password works transparently
• Interesting from a functional point of view is how to migrate to the new functionality. [adaxa: there is a process to convert all unhashed password to hashed]
• Conclusion: the Technical Team has to decide if the contribution makes sense and is compatible

Technical team

• Volunteers for analyzing:Cristina Ghita
• Result of analysis: done. OK
  • Cristina Ghita 08:15, 5 July 2013 (UTC) Comparing against main branch, test feature and check backward compatibility

Review Notes

• Checked and tested code: works nice
• In general, I would prefer to use interfaces and not the implementations
• Also, I would prefer to have constants defined and not use strings directly in code
• we have a process, org.compiere.process.HashPasswords, which updates all existent passwords to use hash and salt
• But I noticed, that the only password which is not hashed is the password for user System, which is excluded by purpose. Why is that?

System is not excluded on purpose, it is just that updates cannot be applied using PO to records with ID = 0. This is taken care of in the HashPasswords process, but special handling needs to be implemented when updating password from the UI as it saves direct via sql without calling the MUser object. --Phib 02:20, 9 July 2013 (UTC)

Open Discussion Items

noted that the password for ad_user=System did not hash .. probably because ID = 0 .. needs checking.