Password Hash
Contents
- 1 Status
- 2 Contributors
- 3 Overview
- 4 Purpose
- 5 References
- 6 Design Considerations
- 7 Glossary
- 8 Functional Requirements
- 9 Functional team
- 10 Acceptance criteria
- 11 QA and test cases
- 12 Development infrastructure
- 13 Technical Requirements
- 14 Technical team
- 15 Data Requirements
- 16 Non-Functional Requirements
- 17 Open Discussion Items
- 18 Closed Discussion Items
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!
Purpose
References
Design Considerations
Assumptions
Dependencies
Constraints
Glossary
Functional Requirements
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.
- Conclusion: the Technical Team has to decide if the contribution makes sense and is compatible
User roles & profiles
Business process definition
User stories
Functional requirements based on business processes
User Interface Mockups
Acceptance criteria
QA and test cases
Development infrastructure
Technical Requirements
Technical team
- Volunteers for analyzing:Cristina Ghita
- Result of analysis: pending
- Cristina Ghita 08:15, 5 July 2013 (UTC) Comparing against main branch, test feature and check backward compatibility
Review Notes
Data Requirements
Non-Functional Requirements
Open Discussion Items
noted that the password for ad_user=System did not hash .. probably because ID = 0 .. needs checking.
