65
edits
Changes
→Authentication
==Authentication==
'''Attacks of Concern'''
* online & offline brute force password guessing
* user enumeration
* mass account lockout(Account DoS)* offline hash cracking (time trade-off hash cracking)
* lost passwords
* Passwords must be 8 characters or greater
* Passwords must require letters and numbers
* Blacklisted passwords should be implemented (contact infrasec for the list)
====Critical Sites ====
Critical sites should add the following requirements to the password policy:
* Besides the base policy, passwords should also require at least one or more special characters.
===Password Rotation===
Password rotations have proven to be a little tricky and this should only be used if there is lack of monitoring with-in the applications and there is a mitigating reason to use rotations. Reasons being short password, or lack of password controls.
* Privileged accounts - Password for privileged accounts should be rotated every: 90 to 120 days.
* General User Account - It is also recommended to implement password rotations for general users if possible.
* Log Entry - an application log entry for this event should be generated.
===Account Lockout and Failed Login===
Account Lockouts vs login failures should be evaluated based on the application. In both caseseither case, the application should be able to determine if the password being used is the same one over and over, or a different password being used which would indicate an attack.
The error message for both cases should be generic such as:
The username or password you entered is not valid
Logging will be critical for these events as they will feed up into our security event system and we can then take action based on these events. The application should also take action. Example would be in the case that the user is being attacked, the application should stop and/or slow down that user progress by either presenting a captcha or by doing a time delay for that IP address. Captcha's should be used in all cases when a limit of failed attempts has been reached.
=== Password Reset Functions ===
===Password Storage===
Separate from the password policy, we should have the following standards when it comes to storing passwords
* Passwords stored in a database should use using the following formathmac+bcrypt function. ** sha512 hashing** Unique per user salt** Private system salt of 20 chars in addition to This combination provides protection against a technical weakness with bcrypt but also provides a site wide key which increases the per user salt** Private system salt would be system only time and not stored with user hash or in the databases.** Need the ability computing required to change/rotate brute force password 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.
===== Background =Old Password Hashes ====I have data on why we are not using bcrypt or something like it* Password hashes older than a year should be deleted from the system. This will * After a password hash migration, old hashes should be published shortlyremoved within 3 months if user has yet to login for the conversion process.
====Migration====
- 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.
==Session Management==
