Jul

7

The Folly of Password Standards

Posted by Keith McMillan

July 7, 2010 | 1 Comment

I was out on a web site today, it doesn’t really matter which one, and was forced to create a profile for the (mis)use of the site’s owner.  I found their password standards to be, well “stringent” would be a good word, especially considering the information (my profile) that I was securing. Their standards for passwords were, and I quote:

  • # It must contain between 6 and 12 characters. Use only characters from the following set: ! # $ % & ( ) * + , – . / 0123456789 : ; < = > ? @ ABCDEFGHIJKLMNOPQRSTUVWXYZ [ \ ] _ ` abcdefghijklmnopqrstuvwxyz { | } ~
  • It must contain at least 4 lowercase letter(s) (abcdefghijklmnopqrstuvwxyz).
  • It must contain at least 2 numeric character(s) (0123456789).
  • It must not contain more than 2 identical consecutive characters (AAA, iiii, $$$$$ …).
  • It must not contain your user name.
  • It must not contain your email address.
  • It must not contain your first name.
  • It must not contain your last name.

Leaving aside for the moment the user name, email address and names, let’s consider the other requirements of this mandate: it has to have at least four lowercase letters, and two numbers, and can’t have more than 2 consecutive characters. I submit that these standards, while creating an effective password, fail for another reason: they ignore the human element.  Anyone faced with creating a complicated password like this will likely write the darned thing down, much like I do, although I keep mine in an encrypted database, and it’s randomly generated.  Writing your password down is not going to make it very secure if someone has access to your (physical) workspace.

Creating overly strong passwords has another downside as well: it’s more expensive for the enterprise to maintain. If it’s so complicated that someone can’t remember it, then when they forget their password, the user has to have it reset. Some organizations do this by allowing you  to reset your own password, but that infrastructure still has to be put into place (cost), and you’re also not able to work until your new password takes effect (cost).

The problem is compounded in a SaaS environment, because all the customers want to have their own password standards, and the the provider of the service needs to come up with a way to satisfy all those requirements at once. Fortunately, there’s SAML, OpenID and other cross-domain authentication mechanisms.

So what’s the antidote? I’ve been surprised that passphrases haven’t gotten more traction, frankly. With a passphrase, you enter a sentence, not just a word, and that sentence is usually hashed to produce a value that’s stored.  Passphrases are easier to remember, and result in passwords that are just as secure as the rule-based ones we discussed above, or maybe more.  For existing applications, it may not make sense to put in a passphrase based system, but for new development it makes a lot of sense.


Comments

RSS feed | Trackback URI

1 Comment »

Comment by Peter H. Coffin
2010-07-07 15:25:24

The more specific the password requirements, the smaller the keyspace, it seems to me.

 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll