Monday, December 3, 2012

10 Tips to Improve Password Security

In a recent Wired article, Mat Honan, the journalist whose Apple and Amazon account passwords were famously hacked, wrote about how passwords will no longer protect us and that they should be killed off. He made some excellent points about the weaknesses of password security both from the individual and company perspectives. Many people don't bother to use very secure passwords. I had high hopes, from the title of the article, that Mat was going to propose a new solution. He didn't.

Though, as Mat pointed out, it's unlikely anything will replace passwords anytime soon, that doesn't mean systems can't be improved. If you work for a company that has an application with users who log-in, there are steps you can take to improve the security of your users and their passwords. Here are 10 methods we use (or are in the process of implementing) to protect our customers at Real Software.

1. Don't Limit Password Length

The longer a password is, the more time it takes to guess it. Netflix limits the length of passwords to 10 characters! Unbelievable! For reasons I'll get into in tip #8, there is no reason whatsoever to limit the length of a password. 

2. Do Have a Minimum Length

Short passwords are easier to guess so have a minimum length. Our minimum is eight characters.

3. Don't Let the User Include Their User Name in the Password

If the user can choose their user name, they will often choose one that is a combination of their first and last names or initials. Many systems use the user's email address which is essentially public. To prevent the user from simply using this as their password or as most of their password, make sure their user name is not present inside the password they choose.

4. Don't Require Silly Characters

Requiring the user to have numbers or uppercase letters in their password achieves nothing. Length and uniqueness is what matters. Numbers and case result in the user creating passwords they can't remember. If they can't remember them, they write them down which is not good. As you will see in tip #6, there are easy ways to get the user to create a long password.

5. Don't Allow the User to Use a Common Password

It's probably not surprising to you that people often choose the same passwords as other people. 4.7% of people choose "Password" as their password. 9.8% of people use either "123456" or "12345678" as their password. Of the top 10,000 most frequently used passwords, 91% of them are in top 1000. At Real Software, we don't allow users to create a password that is on the top 10,000 list. You can download the top 10,000 list for use in your applications.

6. Suggest a Memorable Sentence

Single words are poor passwords because they are easy to guess and encourage (or at least, don't discourage) the reuse of passwords. Instead, suggest to your users that they create a sentence. Sentences will almost always be longer than any single word. The sentence should be connected to your company or the service or product your company provides. That makes the password easy to remember. Imagine if your Netflix password was "Julia Roberts is the bomb!" That's going to be easy to remember because your brain associates film actresses with films. Spaces can be problematic as the user can accidentally type more than one. However, even if they run the words together, it's still long and memorable. An ideal system would account for spaces allowing one space between words but no spaces at the beginning or end of the sentence.

7. Don't Call Them Passwords

Password implies a single word. But you now know that a sentence is far better. Instead, call it a "Personal Identification Phrase". That will encourage the user to create a series of words. In fact, if you support the use of spaces, you could have a three or four word minimum for the user's PIP.

8. Don't Store the User's Password

One reason a hacker will attempt to break into a system is to gain access to user information. They don't want just one user's password, they want all of them. We know that users use the same passwords with multiple systems, even though we warn against this. Should a hacker break in, you don't want to be providing all of your users passwords to the hacker. There's a couple of things you can do to secure your user's passwords:

First, don't store the user's password at all. Instead, store a hash of the user's password. Hashing is basically one-way encryption. When the user enters their password to log in, you simply create a hash of it and compare it to the hashed version you have stored. If they match, you know that the user entered the same password they entered when they set up their password without storing the password itself.

Second, you need to use a strong hashing function. MD5 is no longer enough. You could use SHA256 but there's one that's even better: PBKDF2. The advantage of PBKDF2 is that it's designed to be slow. In fact, it's about 1000 times slower than SHA256. Hackers take those 10,000 common passwords and hash them then so they can compare them to the hashed passwords they got when they broke in to your system. If you use PBKDF2, it's going to take them 1000 times longer. Real Studio users will be happy to hear that PBKDF2 will be available in Real Studio 2012 R2 due before the end of the year.

Third, do more than just hashing their password, generate a unique number that is added to the password before you hash it. This unique number is called a "salt" and can be stored with the user's account. What does this accomplish? As I mentioned earlier, hackers will have a predefined list of hashed passwords and will compare this list against your user's hashed password. If you add a salt, even if the hacker can see the salt for each user, they will have to re-hash those 10,000 common passwords for every user in your database since each user has a unique salt. That makes the amount of work the hacker has to do far greater. In fact, if you have 100,000 users, the hackers job is 100,000 times harder.

Ideally, you should use a cryptographically-secure random number generator. A typical random function (such as the one built-in to Real Studio) will produce well-documented patterns. We are looking into providing a cryptographically-secure random number generator in a future release of Real Studio. Each time the user changes their password, generate a new, random salt.

Last but not least, don't even store their hashed password with their user account. Instead, store their hashed password-salt combination in a separate table that is not in any way linked to their user account. When the user attempts to log in, simply take what they enter, add their salt, hash it, then query your password database table for that value. If you find it, they have entered a valid password. Should a hacker break in, the only way to determine which passwords go with which users would be to guess each users password correctly, which is unlikely.

To make life even more difficult for the hacker, generate several bogus hashes in this table for each valid one you add. That just makes their job many times more difficult. Here's a more detailed article about this last point.

9. Don't Provide the User with a List of Pre-Defined Security Questions

When setting up an account, many systems ask you to choose a security question they will ask you if you forget your password. The problem with this is that the questions tend to be asking about information that is not that difficult to discover online. They tend to use the same questions as other systems as well making the answers even less secure. Instead, let the user provide the question as well as the answer and encourage them to come up with a question that is unlikely to ever be asked of them or would arouse their suspicion if it were asked.

10. Want to Change Your Password? Sign-in Again

Users will sometimes login to a system then forget to logout. Of course your system should automatically log the user out after several minutes of inactivity. However, someone else nearby could go to the computer when the user is away and change their password and email address (if you allow the user to change these themselves) effectively locking the user out of the system. Instead, when the user wishes to change their email address or password, require that they login again so you are sure they are authorized to do so.

Implementing these 10 suggestions will make your systems far more secure and will reduce the chance you'll be the target of bad press if someone breaks into your system and steals your user data.


Beatrix Willius said...

This is a good list. But there are still many websites that don't follow best practices:

- Last week I got my password in the mail after I signed up to a shop. No response yet to my mail.
- One website only had a 8 character password limit. No change yet.
- Another allowed the user to enter a longer password than was allowed when signing in. "Not a problem" was the response.

So much fun!



olivier said...

thank you! :-)

olivier said...

It would be great if you could do another article, but this time on the security of a web server (for the RS WE).