Passwords: Beating the Dead Horse

December 14th, 2010 - Be the First Comment!

Edit: Any comments expanding on password security would be great.

It seems that everyone who is security oriented in computing knows that everyone who isn’t security oriented in computing doesn’t manage passwords properly. It is even the case that some people who do know a lot about security manage their passwords poorly as well. In my eyes the main reasons for poor passwords is 3 fold.

• Poor enforcement
• Lack of education
• Loss of Convenience

Poor enforcement and loss of convenience I believe are the developers fault and I will discuss them later. Lack of education is not entirely the developers fault in my opinion. There is no reason this issue still plagues the internet. We have classes in school about learning basic computer skills and yet we don’t cover password security. To me it is as important or more important then learning things like Excel and Word. A mere day of password security in school could go a long way.

Rolling your own

First and foremost I blame developers for the state of password based security. Developer’s are the front line when it comes to security. If we don’t contemplate security, it is likely the rest of the organization won’t either.  Gawker’s recent password debacle is a prime example of what not to do. It is amazing to me that a network that has technically oriented sites like LifeHacker can use such horrible password procedures (DES with 8 char max). Here are the results and some evidence of encryption failures.

If you are going to roll your own password security at least look into a little bit before you develop a million plus user database. Three of the basics everyone should know are:

• Use hashes, not encryption to store your passwords. Also you’ll probably want to use SHA2-512 or SHA3 once it is available. MD5 and SHA1 are both vulnerable to collision based attacks already and it will only get worse as time progresses. In PHP it is as simple as

  hash('sha512', $pswd)

• Salt the passwords before hashing. Salting is adding a “secret” phrase to the password.

   $pswd = "secret".$pswd."phrase";

• Password Complexity Requirements. Passwords like “password” or “password1″ should never be used. You should enforce some type of password complexity requirement on your site that prevents them from being used. Including symbols, numbers, as well as upper and lower case letters with a minimum length of 12 is what I would consider secure.

To create a very basic authentication system using these concepts you would have a user input their password, then append your salt (secret phrase) to it, and last hash the password. This hashed result is stored (if they’re signing up) or compared (if they’re logging in) to the user information stored in the database. There are many other things to consider when developing an authentication system, but those are basics ANYONE should know (except Gawker apparently).

OAuth, the Single Sign On (SSO) of the internet

All of that being said, I support using  OAuth. They may have their weaknesses, but I believe it is the most effective way to create a secure internet infrastructure. One reason I believe so is that it eliminates the convenience problem discussed below. By making it more convenient for users you may be able to encourage them to use more secure passwords. Since you are basically using a SSO for the entire internet, you can create more complex password policies on the SSO and add very little inconvenience which then translate into better security for all the websites involved. It also centralizes the focus of security on the large OAuth suppliers like Google. Eventually we may be able to complete solve the password problem, but until then I think OAuth are a step in the right direction.

Convenience is the enemy of most security. This is really unfortunate because it encourages people to be less secure to regain convenience. Passwords are something everyone has and most people hate. Even I hate when my domain credentials at work need to be changed. Coming up with a decently secure password that you can remember is a pain.  OAuth allow you to only have one painful password instead of many.

Note: OpenID is another similar concept to OAuth that could also work.

Reality

OAuth aren’t widely used yet.

The solution I use involves creating individual passwords for most sites, and a common password for sites I don’t care about. I then store these passwords for recovery purposes in an encrypted database that I can retrieve. Although it might sound complicated to some, it isn’t. It is however inconvenient. You can use programs like KeePass to help you manage and encrypt your passwords if this interests you, but for most it won’t because it is still inconvenient.

Hopefully someone will be touched by this post and understand a little more about password security and the basic concepts surrounding it.

[ Tags ]: 512, Gawker, keepass, LifeHacker, md5, oauth, openid, password, passwords, security, sha1, sha2
[ Category ]: computer security, programming