How Secure are your Passwords?

In this day and age passwords are everywhere. Email, ATMs, banks, facebook, blogs; they all have them and unfortunately they are all under attack. Passwords, and in a larger sense authentication, has been around for a long time. They can be traced back to ancient guards using passwords to determine who was allowed to pass into protected areas of a city. We still use them in this exact same manner today. With such a long history of use, passwords and breaking them have come a long way.

Today, developers continue to wage the war of protected access to make sure your information stays your information and is only given to the people you grant access to.  This is a very difficult battle since it is not entirely on one front.  It is very easy to see that developers are in opposition to password crackers.  But what you may not realize is that dealing with users is no picnic either.  This will be the first part in a multi-part blog post about password security.

A developer’s main job in the authentication arena is ensuring that password crackers are not able to hack your password and gain access to your information.  Generally, two areas are focused on to increase security: password entering and password storage.  Today, I will focus on password entry.

Follow the Rules

Password entry measures are what a developer would use to limit who, when, where, and how a user enters a password into their application.  The most obvious of these procedures is a password policy.  This is where a developer requires a certain number of characters, usually particular types of characters, and perhaps scheduled password changes.

Password policies walk a fine line between utility and usability, meaning I can enforce a policy that would be insanely difficult to break; but my users will probably never remember their passwords.  Personally, I prefer a website to give me the benefit of the doubt about being an adult.  Unfortunately, most people don’t understand it is their responsibility for having a secure password and these rules are in place to try and make those people not place themselves in danger.

Right now it seems the prevailing theme in this arena is to require an 8 character password with at least 1 upper case letter, 1 lower, 1 number and 1 special character.  Personally, that seems a tall order for a user considering they should use a unique password per site; that’s a lot to remember.

You’re so Vague

Next we have error messages returned by the system.  Developers have to be very careful about what information they return since a hacker could turn that information against them.  For example, if you enter your email address into a site you’ve never been to, more often than not you’ll see a message saying that the user entered was not found.  A hacker could go through a dictionary of email addresses and find which ones actually had an account just by eliminating the ones that got the “not found” message.  It’s fairly standard to be vague about which piece of information is wrong to prevent this type of attack.  Most sites today will overlook this in order to provide a better user experience for legitimate users.  I think that is fine assuming they make up for it in other areas.

Lockout and slowdown

Limiting when a user can enter a password is also an effective way to control entry.  Most sites have a lockout feature where if you enter a wrong password too many times, your account is locked and you have to reset it somehow.  A less visible corollary to this is slowing the amount of entries that can be made in a certain time period.  So, if I take a password that a hacker can attempt 100 times a second; I can significantly increase the time to hack it if I only allow 1 try every 5 seconds.

The important take home here is to include reasonable lockout/slow down times so as not to alienate your users.  If my password policy enforces a password that would take 8 months to brute force at 100 tries/second, then there is no reason to lock a user out after 3 failed attempts.

No Eavesdropping

Lastly, if an application has remote calls and will be sending passwords between a client and server, a developer should make certain an ssl certificate is installed to encrypt that password.  This keeps people from being able to get between you and the server to find out your password.  Or better yet, use some sort of access key that a user can enable / disable to control their flow of information.

In future posts, I will discuss what developers should be doing on the back end of their systems and what users can do to help police and secure the front end.