Changes

Jump to: navigation, search

WebAppSec/Secure Coding Guidelines

1,200 bytes added, 00:52, 1 February 2011
Password Storage
===Password Storage===
==== CURRENT STANDARD ====* Passwords stored in a database should using use the following format that leverages secure hashing and a per user salt.
* Every new password stored in a form like {algo}${salt}${hash}
* {algo} is {sha512},
* {salt} is a salt unique per-user,
* {hash} is algo(salt + password)
 
==== PROPOSED STANDARD ====
Separate from the password policy, we should have the following standards when it comes to storing passwords
* Passwords stored in a database should use the following format.
* Private salt of 20 chars in addition to the per user salt
* Private salt would be system only and not stored with user hash or in the databases.
* Need the ability to change/rotate hashes
 
It would look something like this:
 
* Authentication:
* hash = sha512(userSalt + userPassword + privateSystemSalt[saltVersion])
 
* Storage
* {algo}${userSalt}${hash}${index}
* sha512$1234asbfe$1f40fc92da241694750979ee6cf582f2d5d7d28e18335de05abc54d0560e0f5302860c652bf08d560252aa5e74210546f369fbbbce8c12cfc7957b2652fe9a75$2011-01-11
 
* privateSystemSalt examples
* privateSystemSalt["2010-10-13"] = "01234567890123456789"; // legacy
* privateSystemSalt
* privateSystemSalt["2011-01-01"] = "214bg423df214bg423df"; // legacy
* privateSystemSalt 2
* privateSystemSalt["2011-01-11"] = "^&*FDF3fc_^&*FDF3fc_"; // current
 
===== Background =====
I have data on why we are not using bcrypt or something like it. This will be published shortly.
- The user may already be on the New Hash. Attempt to directly authenticate using the new hash. If this fails, then the password provided by the user is wrong.
 
 
 
<hr>
65
edits

Navigation menu