Cisco Blogs

Numeric Password Follies

- September 25, 2012 - 4 Comments

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:

  1. Require eight-digit, not four-digit PINs
  2. If you must use a short PIN, allow alphanumerics
  3. Use random PINs, not user-selected PINs (i.e. don’t allow users to select their own passwords, if they are numeric).
  4. Configure lockouts after 3 failures, and require manual intervention to unlock.
  5. (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:

  1. Allow your users to have strong passwords.
  2. Assume someone will brute force your users’ web passwords.
  3. Differentiate passwords that can only be entered onto a physical keyboard or keypad from web passwords that can accept automated input.
  4. Implement anti-automation techniques, such as password lockouts or two-factor authentication, to thwart brute force logins.
The provider in question did implement password lockouts, so the immediate problem is solved. The secondary problem of not allowing stronger passwords remains an issue, though much less serious than the original complaint.

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.


All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. ...Thanks for the good article and Per Thorsheim links to enhance this particular keynote...Thanks for sharing

  2. Sure, having a 4-digit PIN on your phone and a real password at the website would be much better. Together with Jeremi Gosney we created some infographics on the Linkedin leak, clearly showing that many people use association elements to the service in question when creating their passwords, or PINs in general. In the Linkedin case, the use of "blue" in passwords were much higher than any other color word. The primary logo color of Linkedin is .... blue. :-) Blacklisting top100 PINs, like the list created by Bonneau/Cambridge, would be somewhat reasonable today - from a isolated security perspective. That is; until users start complaining (by phone/mail), and/or start initiating password resets that may genereate extra cost for them and the service provider. Even without any financial cost, I'll bet users won't be happy, no matter how you explain security to them. I fully believe that implementing better rate-limiting on the server side will give better security than applying restrictions onto end users. Instead of putting restrictions on end users, why not give them the ability to use <= length 64 passwords and explain to them why using long & unique passwords is a good idea, perhaps in combination with a password manager? There is lots more to be told, which is why I am organizing this passwords conference for the third consecute year. :-)

  3. Andy; Good article, although I do not agree on everything. Usability, or should I say security usability, should be a key concern for almost all service providers who considers using PINs as part of the authentication process. There is more research on PINs available: Joseph Bonneau (& others) from Cambridge have done some nice work in this area: Presentation on PIN codes at Passwords^10 by Howard Smith (Oracle UK): (720p MP4 file, 509MB) Last but not least: Passwords^12. A 3-day conference *only* about passwords & PIN codes. December 3-5, Oslo, Norway. Some of the very best password crackers & more coming together to discuss and present more than you ever knew about passwords. More info here: Best regards, Per Thorsheim

    • Excellent comments, Per. I agree that usability is a key concern. In the case that prompted this article, it does not seem necessary for the PIN to be identical on the phone and the website to achieve usability. Could it not be similarly usable if you had a numerical PIN on the phone, and a more complex, but still memorable password for the website? Your list of resources is excellent. I enjoyed the paper by Joseph Bonneau on user-selected PINs. It confirms my assertions that users are terrible at choosing strong numerical PINs, but also indicates that blacklisting common PINs can be effective in cases where 1) attackers get only a small number of guesses (e.g. 3 or 6 tries at an ATM for a bank card) and 2)attackers do not know the birthdate of the victim. They recommend that users do not base PINs on birthdays, and that banks may need to prevent users choosing PINs to completely avoid birthday-based guessing attacks. I wish you luck with your Passwords 12 conference in December. Hopefully it will serve to raise awareness of the importance of password policies.