Numeric Password Follies
I have commented before on numeric passwords, and how they can and cannot be used securely. Apparently, not everyone has been reading my blog. Developer Kevin Burke has apparently discovered a phone company that limited customer passwords to a six-digit code, with only the numbers 0-9 as options. Combined with not having any failed password lockouts, nor requiring any other information besides username (your phone number) and the six-digit password, this is a recipe for disaster.
In my prior article, I mentioned that RSA had four suggestions for using numeric passwords on their hardware tokens:
- Require eight-digit, not four-digit PINs
- If you must use a short PIN, allow alphanumerics
- Use random PINs, not user-selected PINs (i.e. don’t allow users to select their own passwords, if they are numeric).
- Configure lockouts after 3 failures, and require manual intervention to unlock.
- (plus, a suggestion from Kevin Burke’s blog): Require two-factor authentication, such as a code sent to the phone.
While all points above would be helpful, the key ones are #4 and #5. Without lockouts, attackers can guess all possible six-digit passwords in a relatively short time, especially if they start with the commonly used ones. Also, when you allow users to select their own passwords, they choose poorly. They favor representations of dates (MMYYDD) and repeated patterns (343434). Birthdates make terrible passwords, as does any date in the last 100 years. A brute force attack will discover the majority of passwords pretty quickly, especially if they start by exhausting these patterns.
In an attempt to prevent users from choosing terrible passwords, this provider also restricted users from having three repeated digits (e.g. 222), and from having a sequence of three successive digits (e.g. 234 or 987). Unfortunately, as there are approximately 40,000 combinations of the first kind, and 64,000 combinations of the second kind, this had the effect of removing over 100,000 of the possible 1,000,000 passwords that an attacker has to guess when brute forcing passwords. This makes the attacker’s job about 10% easier. Restricting user choice only works if you also limit the number of guesses.
In trying to figure out why this was done, I concluded that the big mistake was tying the same password to the phone and web account interface. The six-digit password is the same one you would use to top up minutes using your phone or to log in to your account via a computer. If you are on your phone, you don’t want to enter a long numeric password that is hard to remember. That makes sense. If someone steals your phone, and wants to use the keypad to guess your password, lockouts can prevent them, combined with the tedium of guessing 900,000 passwords using the keypad. However, once you open that same password to the web, on which automated attack programs can send hundreds of requests per minute, the game is lost.
This isn’t a problem only for this provider or only for the web. Industrial Safety and Security Source reports that brute force attacks are on the rise. The Web Hacking Incident Database lists “Insufficient Anti-Automation” as the third most frequent weakness, and “Brute Forcing” as the fourth most common known attack method leading to web breaches.
I think the most important lessons that web programmers can learn from this are:
- Allow your users to have strong passwords.
- Assume someone will brute force your users’ web passwords.
- Differentiate passwords that can only be entered onto a physical keyboard or keypad from web passwords that can accept automated input.
- Implement anti-automation techniques, such as password lockouts or two-factor authentication, to thwart brute force logins.
The balance between convenience and security is a hard one to strike, and one that programmers and users both struggle with. By following best practices, programmers can provide secure options for users while severely limiting the ability of automated attackers to compromise that security.