Passwords

I’m getting increasingly annoyed at retarded password policies.

There are a few things that particularly annoy me:

  1. Emailing your passwords to you, or asking you to confirm passwords over the phone
  2. Sites that limit you to a arbitary password length or character set
  3. Sites that limit you to an arbitary password length and truncate the password when creating it, but do not truncate the password when entering it.
  4. Requirements to change your password regularly
  5. Not salting password hashes

The first one is particularly bad. It indicates that they are storing your password in a way that is reversible, meaning if the site gets hacked, your password is wide open as well. If they ask you to confirm your password over the phone, and I’ve had this from two companies, this is the height of security ignorance, because it means that they are storing your passwords in plain text and is completely visible to the operator taking the call.

Number two is just plain annoying. If you have a password setup that is longer, it means your password is not as secure as it could be. If I want to set my password to “{Y`>v[S]e7,f&HA8ZUK]rdbX-QFqt?t9!}a4z<wmgRa’YB25GYF:HBdK1V)/” then I should be able to. Number three is not only annoying, but can actually lock you out of critical accounts. A good example of this that prompted me to write this post was the Verified by Visa website. The website has a restriction on the length of passwords you can use, but it does not tell you this. Given its a fairly sensitive login, I naturally wanted a strong password for it – so I generated a completely random alphanumeric username and password. After accepting the password and confirming my other details the site happily confirmed my registration. Later that week I attempted to log in, only to find my password no longer worked. You see the site had truncated my password as I entered it, leaving my password some number of characters shorter. A password reset later to a shorter password and the problem was resolved.

Number four seems to be a fairly common problem in enterprises. At its basic level it boils down to top level IT management not understanding that imposing overly harsh restrictions on user passwords just leads to creative workarounds. See this slashdot post for some examples of this.

Number five is more of a technical issue than a policy, but simply storing passwords as an MD5 sum or some other basic hash is just not good enough. Take the following website. It provides a service to reverse an MD5 hash to a string by having a list of passwords listed against their hashes. It does not crack the password, you cannot ‘crack’ MD5 sums, because they do not contain the original data. However if the password is common enough, it can be reversed by being able to match one to the other. Salting helps to reduce this by mangling the resulting hash to something less common that is unique to the site.

Its time to enforce a standard password system across the web. Google, you want ideas of how to make the web better? Heres my suggestion. The standard should specify a set of requirements that all websites, enterprises and services should follow. It should apply to online and offline services.

Here are my suggestions for a spec:

  1. No upper password limit or limit on complexity – want a unicode character in your password, be my guest!
  2. A reasonable lower limit on password length with warning to the user when below the recommended length
  3. No password retirement policites – ever!
  4. Optional support for physical key generating devices such as RSA SecurID
  5. No plain text passwords, passwords saved in hash form with unique salt per user per site
  6. Client side password salting and hashing to not send raw passwords over unsecured links

As a user there are plenty of things you can do to guard against unsecure sites. My number one suggestion is the following free combination: DropBox and mobile KeePass. KeePass is a very useful tool that both generates and stores passwods securely. When used in combination with online service DropBox it makes a great tool into an essential one. DropBox provides two things – syncing of your passwords between multiple machines (work, home, laptop etc), and a history and backup in case of accidents. If you accidentally delete a password or your hard disk dies, DropBox has your back! To use it effectively use a different password for every site and store it in keypass, and especially never use a password that is the same as your email password.

Comments (4)

TomJuly 19th, 2009 at 4:49 AM

Client-side hashing is not a method to securely send passwords over unsecure links. If servers accepted hashed passwords, then an eavesdropper could sniff the client-side hashed password and use that to authenticate with the server.

Unsecured links are unsecure.

FWIW, another method to increase the time needed to perform a dictionary attack is key strengthening:

key = hash( password + salt )
for 1 to 65000 do
key = hash( key + salt )

(as described in http://en.wikipedia.org/wiki/Key_strengthening#Hash_based_key_strengthening )

Or, if you’re insane this might increase the cost of that attack even more:

key = hash( password + salt[0] )
for 1 to 65000 do
key = hash( key + salt[i] )

where salt[i] is a 65001-array of potential different salts. This is off the top of my head though, so it could easily be prone to some problem I haven’t thought of (as well as space concerns).

TomJuly 19th, 2009 at 4:57 AM

Gah. It messed up my indentation. It was supposed to be

key = hash( password + salt )
for 1 in 65000 do
………. key = hash ( key + salt )

and

key = hash( password + salt[0] )
for 1 to 65000 do
……… key = hash( key + salt[i] )

icStaticJuly 19th, 2009 at 9:51 AM

Yeah, that makes sense. BTW, when I talk about client side hashing I mean something along the following lines:

Server sends client a single use nonce
Client hashes password and includes the nonce with it
Client sends back the final hash

Unfortunately this assumes that the server already has a hash of the password on its own without the nonce, which again leaves it open to attack, given you can’t transmit that without again leaving it open to attack.

People have written entire books on digest authorisation so I won’t claim to know what I’m talking about, but I definitely don’t want my passwords sent in plain text over the net!

SherriMay 14th, 2015 at 6:50 PM

Very nice blog post. I absolutely love this site.
Continue the good work!

Leave a comment

Your comment