Note: This is copied from my April 4th blog post at http://blogs.catapultsystems.com/BA. My posts are generally about Quality Assurance related issues.
In my last post, I mentioned that I was joining my local chapter of OWASP and would write about any interesting presentations. The first one that I attended was called "Supercharged John the Ripper Techniques" and was presented by Rick Redman of KoreLogic Security. His presentation was a real eye-opener to me, especially in my role as a business analyst.
Even before seeing Rick Redman's presentation, I was highly aware of the importance of having good policies for generating secure passwords. The story about Oracle's MySQL.com hack that I mentioned in my last post was just the latest of many stories that I've read about web passwords being stolen. I knew that passwords should be encrypted when stored; that they should require at least one number, at least one capital letter, and at least one special character; and that they should be at least 8 characters long. However, I wasn't aware of just how weak these safeguards could be.
Rick explained a number of reasons why these typical password safeguards aren't enough, especially on the web. Most of the reasons have to do with the fact that people can't easily remember a lot of passwords, so they take some actions that reduce the strength of their password.
One of the most well-known password hacks is related to RockYou. This hack made the news because it contained a huge number of passwords, and the passwords were all stored in plain text. SC Magazine wrote an article about the stolen passwords, and the results were surprising. The 10 most common passwords for the RockYou site were "123456", "12345", "123456789", "password", "iloveyou", "princess", "rockyou", "1234567", "12345678", and "abc123".
You may think that by requiring longer passwords and special characters, users would not be able to pick such easy to crack passwords. However, Rick pointed out that this is a false assumption. Many people simply capitalize a first letter and replace another letter with an obvious replacement character such as replacing an "a" with an "@" or an "l" with an "!". Between his presentation and the rules of the KoreLogic "Crack Me If You Can" contest, you can get a good idea of what some common passwords are that follow complex rules but are still easy to crack. Is a password like "June2010!" or "NewYear2010!" really that hard to crack if someone is aware of the common patterns?
In the case of RockYou, the passwords were stored in plain text. I would hope that most business analysts, as well as most others involved with software development, would realize that storing passwords in plain text is a bad practice. However, I did not realize the dramatic effects that different types of encryption could have on the ability to crack passwords. The KoreLogic "Crack Me If You Can" statistics page shows that the percent of cracked passwords by hash type ranged from 0% to 100%. For some hash types, there are relatively simple passwords that were left uncracked.
Since RockYou is a social gaming site, the consequences of a hacked account really shouldn't be that bad. However, because many users use the same user ID and password at multiple sites, people were able to use the password information to steal real money from people at PayPal and other sites.
There are concrete actions that you can and should take to protect yourself and to protect your company from hackers who might steal your password.
On a personal level, you can make sure to give yourself a unique, strong password at each website where you do business. Based on the information that Rick presented, this means that you want to avoid any easy to guess patterns in your password. One way that you can do this while still remembering your password is to think of a phrase and use the first letter of each word in the phrase as your password. If you use this method, you would want to also mix in some numbers and symbols and ensure that the password is 10 characters or more. For example, you could use the phrase, "I want a strong and secure password for all sites now," to generate a password of "!w@S@sp4@sn". This is a password that you should be able to remember and would be difficult for a hacker to crack. Unfortunately, I have found that some sites, including some financial sites, don't allow special characters in your password, which I found surprising.
You can also figure out a way to add some information about the site that you are using into the password to help generate unique passwords for each site. However, you don't want to use the site name in your password. It is important to have different passwords at each site just in case one of your passwords gets stolen.
Also, make sure to choose security questions that can't easily be guessed by people. It doesn't make sense to create a secure password with security questions that are easily guessed or discovered.
You might be tempted to push the responsibility of generating a secure password completely onto your users. After all, it's clear that even if you put rules in place to help users generate a secure password, they can still generate simple to crack passwords. In addition, when you put too many rules on a password, you may lose business because some users will get frustrated with the rules. However, just one incident of losing users' passwords will result in negative publicity. In addition, there's a growing movement to try to hold software vendors legally liable for insecure software. If you're interested in the potential legal ramifications, you can read "Tort Liability for Vendors of Insecure Software: Has the Time Final..." by Michael D. Scott for a good overview.
Rick pointed out some key ways that a company can help protect their users in his presentation. He said that companies should "encrypt their hashes with stronger formats," "force password complexity," "require/force passwords changes/rotation," and "educate their users." He points out that even these actions aren't failsafe, but they make the passwords a lot safer, which protects both your users and your company.
I'd like to hear about your experiences with setting password rules. How have you decided on password rules for past applications? What considerations did you need take into account other than security? Do you have any other tips for generating secure passwords or keeping passwords secure?