Towards smarter password management (part 2)

Passwords suck. But we're stuck with them for awhile. This little series of articles is my attempt to explore how you can implement a password store and login page that makes the best of it.

A typical web app that has a user name/password store typically has two points of entry for an attacker:

A. The system's internal password store.

B. An anonymously-accessible login page.

In part 1, I shared some thoughts about (A), and this part will focus on (B).

Here are a modest list of goals for a good login page. Do you concur?

Goal 1: Prevent online password-guessing attacks.

This is the biggie. Imagine an attacker running automated dictionary and brute force attacks against your user store from the comfort and safety of his home in (insert name of impossible-to-prosecute-in foreign country) from the hundreds of machines on his personal zombie bot net. I've seen lots of articles that talk about the need to achieve this goal, and some even offer rudimentary suggestions on how it might be done. I'm hoping to take a broader view of the topic and get to a solution that addresses more than just this one goal. And I plan to follow up with code that you can use in your ASP.NET websites.

Goal 2: Prevent information leaks.

Login pages are inherently risky. For some websites, this may be the only page accessible to anonymous users. And a login page provides a direct entry point to a highly valuable resource: your user account store. So you want to be very careful to design your login page so that it doesn't leak information. The most obvious example of unintended information leakage is accidentally validating user names for the bad guy.

User names aren't typically considered secret, but there's no point making it easy for an attacker to collect a list of valid user names at your website. Knowing a valid user name just gives the attacker a target for a password guessing attack, or fodder for a social engineering attack. A simple example of a login page that doesn't meet this goal is one that has a different error message depending on whether the user provided a valid user name or not. Say, invalid user name, as opposed to the more vague invalid user name or password. This fights against usability, but it's a pretty reasonable tradeoff for most sites. A more subtle violation is where an attacker can use a side channel such as timing to determine a valid user name. If (as I discussed in part 1) you are using an iterative hash to validate a password, but you only perform this lengthy computation if the user supplies a valid user name, then the attacker may be able to tell the difference between a good and bad user name by keeping stats on how long it takes for your login page to return a response.

Similarly it would be bad if the page leaked information about the privilege level of a user, because when the website is the target of attack, high privilege user accounts are the juiciest targets.

Goal 3: Prevent client-side capture.

Many browsers offer to remember passwords for the user. I could write an entire article on the plusses and minuses of stored passwords, but I think we all agree that on shared computers (think Internet Cafe) we would rather that the user NOT store her password in the browser. If there's a keylogger on the box, her password is already compromised as soon as she types it, but there's no point inviting attack by leaving stored passwords in the browser as well (one of the evils of passwords is that they have long lifetimes).

Have you ever noticed that some websites don't work so well with browser-stored passwords? It's like the browser doesn't recognize the password field (and often the user name as well). Knowing how to do this seems like it'd be a good tool in your bag of login page tricks.

Goal 4: Do all of this without introducing Denial of Service (DoS) vulnerabilities.

You don't want to end up with a login page that makes it easy for an attacker to prevent legitimate users from logging in.

Goal 5: Do all of this while keeping your login page easy to use for legitimate users.

If your login page is hard to use, your customers will hate you. This is not good from a business or a security standpoint.

Do you agree with the goals I've listed here? Am I missing anything?

Next up, we'll look at some random bits of advice that I've found during my research, and see how they help achieve these goals.