Occasionally, someone who is learning about security will ask insightful questions like “how long should passwords be?” or “how long should it be before a user is logged out for inactivity?” The correct answer, of course, is “it depends” followed by a smoke bomb and a disappearing act. If, however, you are cornered with a question like this, I think there are some reasonable guidelines everyone can agree on.
There are things you can get 100% right (like eliminating cross-site scripting) and there are some things that you get for free (like using a strong session ID token from a framework). But, there can be big tradeoffs in performance or usability for certain security mechanisms. The appropriate tradeoff varies with the risk profile of the site. Let’s take a look at a few example security requirements, viewed through the light of two site risk profiles.
Weak: Something with no financial or private data. Forums, wikis, twitter, etc.
Strong: Anything with financial or private data. Banks, webmail, web hosting accounts, etc.
Is this too coarse to describe every site in the world? Yes, but it’s a start.
Use of SSL
Weak: SSL is optional for everything but the login page (and the form it’s served on).
Strong: HTTP redirects to HTTPS. SSL only.
Account Lockout
Weak: Either no brute force detection or basic request rate throttling.
Strong: Time-based lockout with increasing durations (5 minutes after 5 bad attempts, 10 minutes after 10 bad attempts, 20 minutes after 15 bad attempts, etc).
Session Timeout
Weak: A few weeks. Seriously! Look at GMail.
Strong: After ten minutes of inactivity, and no longer than a few hours, even with activity.
Password Strength
Weak: Six characters, and your password cannot be “password” (seriously)
Strong: At least eight characters, at least three character sets (upper, lower, numeric, special)
Password Reset
Weak: Email-based reset.
Strong: Email plus secret question/answer based reset.
Page Caching
Weak: All pages can be locally cached
Strong: No pages are locally cached
Username Enumeration
Weak: After a failed login, tell the user if the username they entered is valid.
Strong: After a failed login (or successful password reset, etc), do not disclose if the username the use user entered is valid.
Your requirements may vary, but I think this covers some of the common policy-based ones. Wouldn’t it be a happier web application security world if everyone followed these guidelines?
I’ve recently been accepted to the Masters program at the iSchool at UC Berkeley. I'm not starting until the Fall, but I’m already experiencing some life changes. I’ve moved out of my house in Long Beach, and I’m currently staying with friends and family throughout Southern California. I’m stopping work at Foundstone on July 1st, and moving up to Berkeley sometime in August. Hopefully, that will give me a little summer vacation to relax while I prepare to go back to school.
I completed my undergraduate work at Berkeley, so this will be a homecoming. I visited the iSchool during the open house and my expectations were exceeded by the students, both prospective and current, and the staff. It’s a “post-disciplinary” program that is centered on information and technology, but branches into fields like psychology, security, usability, economics, business, and sociology. I am not set on what I want to study and research, but I know that I’ll have plenty of inspiration from like-minded peers – check out the cool final projects from this year. The school itself is located in South Hall, the oldest building in the UC system.
I’ll continue to keep this blog updated. I hope to find some time to increase the content and improve the functionality of the site, as well as work on my other projects during the break. To be continued!