Saturday, March 19, 2011

Signs of Broken Authentication (Part 3)


Today, I'll cover two more warning signs of broken authentication. But first, a word from our sponsor. (Warning: Shameless plug ahead.)

Hey boys and girls! Do you have trouble thinking up new secure passwords for each new web site that you visit and have resorted to using passwords like “password1”, “password2”, “password3”, etc. because you know someone has told you to use different passwords for each site? Or you actually have secure passwords for your sites, but you have trouble remembering them? Well, look no further than Kevin Wall's Creating Good Passwords. You'll be glad you did.

We now return you to our regularly scheduled blog.

Red Flag #3: Mapping Password Characters to Digits for Entry via Telephone Keypad

Another red flag which I have been running across much more frequently, are sites where they allow you to enter your password via a standard telephone key pad. You can check this if you are aware of sites that allow this. For instance, if your password was “JeHgr72w”, can you enter your password as “53447729” from the numeric keypad of your phone? If you can, you know that they are very likely mapping the characters in your password to digits 0 through 9 as arranged on a phone keypad. In such cases, this really dumbs down the entropy of your password—much worse than simply restricting which characters they allow you to use. If you run across such sites, I would advise you to choose the maximum length password that they allow. You would think that this would not be too common with sites that hand confidential data, but just last year, I discovered that a site handling our benefits weas doing this. I ran across it when I called their customer service desk and they asked me to confirm who I was via my password. When I asked how to enter alphabetic characters on a telephone key pad and they incredulously answered “for A, B, or C, enter 2; for D, E, or F, enter 3; etc.”. I should have been suspicious when their web site didn't allow me to choose any special characters at all. (See Red Flag #2.) So far, the sites where I've encountered have been limited to IVR systems associated with customer support. I guess one could argue that this is better than requesting sites requesting things like your SSN for verification of identity—especially in cases when they shouldn't be using your SSN any longer any longer (health care services come to mind). But the down side is that this site is dumbing down potentially strong passwords without the knowledge of their users, so consumers beware!

Red Flag #4: No Account Lockout

Another authentication red flag are sites that support no account lockout after so many consecutive failed login attempts. If a web site allows someone to guess unlimited attempts of your password, you had better have a really strong password because there's nothing there to slow the attacker down.

So what should developers do? Well, it should be obvious that what they do NOT want to do is to permanently lock out an user account. If you thought help desk calls about password resets were expensive before, just try implementing a permanent lockout. Some hacker will come along and hit your site with something that guesses user names (in general, not very difficult to guess especially if you have a list of first and last names for users) and just try N intentionally incorrect passwords for each user name (where N is the threshold for failed attempts where the site locks out the account). If you are the developer of such a site that implements this permanent lockout policy, lets just say for your sake, I hope you are away on vacation in the deep woods of Canada where no one can find you if / when this happens.

So what's the correct approach? Well, the idea is to sufficiently slow down an attacker who is doing an off-line attack. So pick some reasonable number of password attempts (5 seems about right), and if there are (say) 5 consecutive failed login attempts for a specific user name, then temporarily lock out that user account for some short amount of time (between 5 to 10 minutes is good). On the password attempt, you should display an error message that says something like:

You're user account has been temporarily locked out for T minutes after N consecutive failed attempts. Please try again in T minutes.

where T and N are the lockout duration and failed attempt threshold respectively. A similar error message would be displayed if a login attempt was made while the account is temporarily locked out.

Once a user successfully authenticates after an account had been temporarily locked out, it also a good idea to display a message that effectively gives notice to the user that this had happened and the time when it occurred. This helps the user know that someone else may have been trying to crack their account, and if so, they may wish to change their password as a result.

POLICY NOTE: If your company has a policy to not divulge failed whether a login attempt failed because the user name or password was incorrect (e.g.,”Login failed: Invalid user name or password” rather than “Login failed: Invalid user name” / “Login failed: Invalid password”), then you need to temporarily lock out even invalid user accounts! Otherwise, an attacker can use this account lockout information to discern whether or not a guessed user name is valid.

1 comment:

  1. If you are implementing this control yourself, you should a sliding window pattern. The user is allowed N attempts over a period of T minutes. For example, a user can attempt 5 authentications within a 10 minute window. This prevents user from getting burned today after one one attempt when they failed 4 times yesterday.

    ReplyDelete