Confirmed users
81
edits
WebAppSec/Secure Coding Guidelines: Difference between revisions
WebAppSec/Secure Coding Guidelines (view source)
Revision as of 12:57, 20 April 2012
, 20 April 2012→Session Management
| (5 intermediate revisions by 2 users not shown) | |||
| Line 83: | Line 83: | ||
A sample of this code is here: https://github.com/fwenzel/django-sha2 | A sample of this code is here: https://github.com/fwenzel/django-sha2 | ||
Keep in mind that while bcrypt is secure you should still enforce good passwords. | |||
As slow as an algorithm may be if a password is "123" it still would only take a | |||
short amount of time before somebody figures it out. | |||
==== Old Password Hashes ==== | ==== Old Password Hashes ==== | ||
* Password hashes older than a year should be deleted from the system. | * 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 log in for the conversion process. | * After a password hash migration, old hashes should be removed within 3 months if user has yet to log in for the conversion process. | ||
====Migration==== | ====Migration==== | ||
The following process can be used to migrate an application that is using a different hashing algorithm than the standard hash listed above. The benefits of this approach is that it instantly upgrades all hashes to the strong, recommended hashing algorithm and it does not require users to reset their passwords. | The following process can be used to migrate an application that is using a different hashing algorithm than the standard hash listed above. The benefits of this approach is that it instantly upgrades all hashes to the strong, recommended hashing algorithm and it does not require users to reset their passwords. | ||
| Line 133: | Line 139: | ||
===HTTP-Only Flag=== | ===HTTP-Only Flag=== | ||
The "HTTP-Only" flag should be set to disable malicious script access to the session ID (e.g. XSS) | The "HTTP-Only" flag should be set to disable malicious script access to the session ID (e.g. XSS) | ||
===Login=== | |||
New session IDs should be created on login (to prevent session fixation via XSS on sibling domains or subdomains). | |||
===Logout=== | ===Logout=== | ||
Upon logout the session ID should be invalidated on the server side and deleted on the client via expiration/overwriting the value. | Upon logout the session ID should be invalidated on the server side and deleted on the client via expiration/overwriting the value. | ||