Weak and Strong Web Security Requirements


Jun 5, 2009

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?