Thursday, August 23, 2012

How to identify websites with weak password storage

A lot of high-profile hacks have been in the news lately and various tech journalists are trying to sort through how to fix the problems of weak password selection and password storage that are rampant. While I have technical solutions to the problems, you, the user, are at the mercy of most programmer's whims.

However, there is something you can do about it. Once you know what to look for, you can identify websites that have weak password storage mechanisms behind the scenes. Today, I'll show you how to identify those websites that are storing your password incorrectly so you can contact them and educate them.

There are several common ways that passwords are stored:

  • Plain text.
  • Encrypted.
  • Hashed.
  • Salted and hashed.
  • 'bcrypt'-style (bcrypt, scrypt, etc).

If you use a tool like KeePass, you will run into quite a few websites that store passwords in plain-text and possibly encrypted with a single key. The programmer thought "15 characters is plenty for a password" and made the column in the database accept a maximum of 15 characters. They then proceeded to simply store your password in the database without doing anything to it. 15 character passwords are weak to begin with, but you can spot this sort of password storage with phrases like "8 to 15 characters" below or next to the password field.

Now let's assume the website accepts any number of characters for a password. This is good, but did it take a while to login or was it instantaneous? With the Internet, it is hard to tell, but if your browser starts receiving response data from a login request in less than 1/4th of a second, you can be pretty sure that the password is merely hashed or salted and hashed. Again, this is the wrong way to store a password. If a hacker obtains the user database, it has been proven that simply salting and hashing won't keep your password securely stored. It has to take significant CPU time. Some algorithms are being invented that also consume RAM (e.g. scrypt).

Assume the programmer was smart enough to realize they needed to use bcrypt or a similar algorithm. Now, let's look at password requirements. Are there restrictions such as "must use a combination of upper, lower, numbers, and a strange character" or can you enter in any old password? Long password phrases and password sentences are actually stronger than shorter, harder to remember character combinations. The length of the password matters - the longer it is, the more secure it is.

Does the website let you login at one location on the website with your username and very long password but not other locations with the same password but gives the indication that there is an account there already? This happens when disparate software products are used and the website operator is synchronizing accounts to various product databases. The correct solution is to use a single sign-on system instead of pushing login credentials around and when you can't login with a long password on some forms, it is because the database behind the scenes is storing the password in plain-text. With this approach, you can quickly determine that one user database might have stored your password securely, but another database has it in plain-text. Which database do you think that hackers will target/obtain?

Next, does the website require you to enter "security questions"? Answering security questions actually eliminates the need for knowing the person's password. Plus, they offer a treasure trove of personal information in the event that the database is stolen because, while the password was hashed, the security questions and answers are likely stored as plain-text. Unfortunately, this practice is common and required to simply access a website.

Does the website log you in over HTTPS? Look for that security lock in the browser's address bar. If you aren't being logged in securely, anyone sniffing web traffic can see your login credentials as they pass over the wire in plain-text. WiFi sniffing is a fairly common practice. Given that website operators can obtain valid SSL certificates for free these days from StartCom, there is no excuse to not be doing HTTPS logins for any website.

Does the website do two-factor authentication when you login from another computer? Two-factor authentication is where you login and a SMS message or e-mail is sent that contains a code you have to enter in order to complete the login process when the website detects that the login has taken place from a different computer or location. Something you know (your password) and something you have (a cell phone). This is fairly rare to find but financial institutions, medical benefits providers, anyone else with your social security number on record, anyone storing your credit card number, and large websites should be doing this universally.

Well, that's all I'm coming up with off the top of my head for things you can spot at a glance and things I've run into over the years. Got others? Write a comment.