Weak and Strong Web Security Requirements

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?