65
edits
WebAppSec/Secure Coding Guidelines: Difference between revisions
Jump to navigation
Jump to search
WebAppSec/Secure Coding Guidelines (view source)
Revision as of 23:47, 23 December 2010
, 23 December 2010→Password Storage
(→Layout) |
|||
| Line 88: | Line 88: | ||
* Passwords stored in a database should using the following format that leverages secure hashing and a per user salt. | * Passwords stored in a database should using the following format that leverages secure hashing and a per user salt. | ||
* Every new password stored in a form like {algo}-{salt}-{hash} | * Every new password stored in a form like {algo}-{salt}-{hash} | ||
* {algo} is {SHA- | * {algo} is {SHA-512}, | ||
* {salt} is a salt unique per-user, | * {salt} is a salt unique per-user, | ||
* {hash} is algo(salt + password) | * {hash} is algo(salt + password) | ||
* If upgrading from an existing scheme such as md5 hashing with no-salt, then a conversion process can be established. This conversion will occur whenever a user logs into the system. First attempt to authenticate the user via the above scheme (e.g. unique salt and sha- | * If upgrading from an existing scheme such as md5 hashing with no-salt, then a conversion process can be established. This conversion will occur whenever a user logs into the system. First attempt to authenticate the user via the above scheme (e.g. unique salt and sha-512). If that fails then authenticate via the old scheme (e.g. md5) and create a new hash in the above scheme(e.g. unique salt and sha-512). Remember to also clear out the old hash value after the conversion is complete for the user. | ||
* After a six month period of changing from md5 to sha-512, all md5 hash entries should be cleared from the system. | |||
* As part of the password storage and user table, the last password change and last login should be included in the table for tracking. | |||
==Session Management== | ==Session Management== | ||