WebAppSec/Secure Coding Guidelines: Difference between revisions

Jump to navigation Jump to search

WebAppSec/Secure Coding Guidelines (view source)

Revision as of 23:47, 30 March 2011

1,725 bytes removed ,  30 March 2011
→‎Authentication
Line 20: Line 20:
==Authentication==
==Authentication==
'''Attacks of Concern'''
'''Attacks of Concern'''
* brute force password guessing
* online & offline brute force password guessing
* user enumeration  
* user enumeration  
* mass account lockout
* mass account lockout (Account DoS)
* time trade-off hash cracking
* offline hash cracking (time trade-off)
* lost passwords
* lost passwords


Line 31: Line 31:
* Passwords must be 8 characters or greater
* Passwords must be 8 characters or greater
* Passwords must require letters and numbers
* Passwords must require letters and numbers
* Blacklisted passwords should be implemented (contact infrasec for the list)


====Critical Sites ====
====Critical Sites ====
Line 38: Line 39:
Critical sites should add the following requirements to the password policy:
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.
* Besides the base policy, passwords should also require at least one or more special characters.
==== Global Disallowed Passwords ====
We should have lists where people pull from where user users can't use
these passwords. Right off the bat, we should disallow "password" and
anything like it such as "p@$$w0rd".
* http://www.whatsmypass.com/the-top-500-worst-passwords-of-all-time


===Password Rotation===
===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.  
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 days.  
* 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.
* 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.
* Log Entry - an application log entry for this event should be generated.


===Account Lockout and Failed Login===
===Account Lockout and Failed Login===
Account Lockouts vs login failures should be evaluated based on the application. In both cases, 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.  
Account Lockouts vs login failures should be evaluated based on the application. In either 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 error message for both cases should be generic such as:  
Line 60: Line 54:
   The username or password you entered is not valid
   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.
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 Reset Functions ===
Line 74: Line 68:


===Password Storage===
===Password Storage===
==== CURRENT STANDARD ====
* Passwords stored in a database should 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
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.  
* Passwords stored in a database should using the hmac+bcrypt function. This combination provides protection against a technical weakness with bcrypt but also provides a site wide key which increases the time and computing required to brute force password hashes.
** sha512 hashing
** Unique per user salt
** Private system salt of 20 chars in addition to the per user salt
** Private system 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
A sample of this code is here: https://github.com/fwenzel/django-sha2
    * privateSystemSalt["2010-10-13"] = "01234567890123456789"; // legacy privateSystemSalt
    * privateSystemSalt["2011-01-01"] = "214bg423df214bg423df"; // legacy privateSystemSalt 2
    * privateSystemSalt["2011-01-11"] = "^&*Fer3fcj^&*FDF3fc_"; // current
 


===== Background =====
==== Old Password Hashes ====
I have data on why we are not using bcrypt or something like it. This will be published shortly.
* Password hashes older than a year should be deleted from the system.
* After a password hash migration, old hashes should be removed within 3 months if user has yet to login for the conversion process.


====Migration====
====Migration====
Line 135: Line 104:


- 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.
- 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>
<old process below - to be removed>
* 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==
Clyon
65

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/295380"

Navigation menu