A new version of my white paper entitled "Best Practices for a Secure Forgot Password Feature" is available. You can download the white paper here. No significant changes were made in terms of content, but it does have fewer pages and a more pleasing look now. The link I had given out previously is no longer valid.
Saturday, September 11, 2010
Wednesday, September 8, 2010
A Consumer Reports blogger has been taking Facebook to task for allowing dictionary words to be used as passwords. I can't confirm that Facebook actually forbids the use of these words like the blogger claims. The signup page did not reject the word "animal" when I tried it, and their password strength FAQ does not state that dictionary words are banned.
The flak got me to thinking about password complexity rules in general. It needs to be evaluated when assessing the security posture of a web application. I see huge variety in the password rules that are being used. That's not the problem. It makes sense that highly sensitive applications, such as financial or governmental, should enforce stricter requirements. The problem I see is that the password rules simply aren't strong enough, ever. Identifying this weakness calls for a manual test or a code review. It is not something a web app scanner like WebInspect or AppScan would flag. Maybe that's part of the problem.
Below are the password rules I normally recommend for Internet-facing web applications.
- Minimum password length of 7
- Maximum password length of 20 or more
- Require at least one uppercase letter
- Require at least one lowercase letter
- Require at least one number
- Allow special characters
- Do not allow any part of username to appear in the password
- Do not allow the user's first or last name to appear in the password
- Do not allow any form of the word “password”
- Do not allow the same character three or more times in succession
Please let me know if you have any other suggestions on this subject!