Nearly every week now we can read about a data breach case somewhere, where millions of user accounts and potential other sensitive data has been compromised. Most people are not even shocked by such news anymore, as it is starting to become humdrum.
One of the most common attacks used in such breaches is an SQL injection. This attack has ranked first place on OWASPs Top 10 faults in Web applications for many years. There are several well-known methods to prevent SQL injections, but unfortunately it is still often encountered in productive sites. Furthermore, mis-configured Web servers and vulnerabilities in remote management tools can allow attackers to gain access to systems and read potentially sensitive files.
There has long been a heated discussion about how best to store passwords and that discussion is still ongoing. Most people agree that storing passwords in clear text in a database is not a good idea. Although sadly it is still done in a lot of places, usually with the excuse of “no one has read access to the database, so what could possibly go wrong?” As history has repeatedly shown, this argument does not hold true for long.
As a user, you normally do not know how your passwords are stored on a service. One enlightening trick can be to use the password reset function. Some services will send you an email with your password in clear text, which obviously means that they store it in clear text to begin with. If in doubt, you can send the service an enquiry, but most will probably just assure you that they are using state of the art cryptography to protect your password, which does not tell you much.
But the keyword is correct, as most systems have started to use cryptographical one-way functions; so-called hash functions like MD5 or SHA1 are being used to store passwords. Note that these are not password functions, but rather functions that are normally used for creating message digests. By using them on the password and only storing the hash value, the problem of clear text passwords disappears. Unfortunately, attackers can create “rainbow tables”, with pre-computed pairs of passwords and corresponding hash values. With today’s cloud services, generating rainbow tables does not take too long and the combination values can easily be stored. Such a set up would allow a simple lookup to break all common passwords within seconds.
To make it more difficult for rainbow tables to break passwords, services can use salt. A salt is a long random string, which is combined with the password before hashing. When used per user, this adds extra complexity as it means that even if two people have the same password (e.g. 123456) they would end up with a different hash in the table. More importantly, the attacker now needs a rainbow table for every possible salt, thereby making it a lot more cumbersome to crack the passwords of many users at once. However, brute-forcing the password of one specific user (e.g. an administrator) is still possible.
At this point, iteration or key-stretching can be introduced. By iterating hash functions over and over again, the whole process is slowed down. For normal usage during logon, a small delay does not matter much, but for brute-force attacks, this can add a few thousand years to your key breaking time. Some examples that can easily be integrated are bcrypt and PBKDF2. Of course, the bar can be raised even higher when using two-factor authentication, for example Symantec’s VIP service.
Regardless of the function that is used to store the passwords, it is always a good idea for users to utilize different passwords for different services. As if you use the same password on all services, once one of them has been broken (possibly due to a bad password storing process), then all of the others become known to the attacker as well. Whenever a data breach occurs, attackers typically try the email password combinations on other services—just to see if they’ve gotten lucky.
Needless to say that using a strong password in the first place is a must. “123456” is simply not a strong password and should not be used. If you cannot remember all of your different passwords, you can use a password manager. Your passwords can then be stored on your smartphone so that you have them with you all of the time. Of course, you have to ensure that when the smartphone is lost, no one can access your password manager, but that’s a whole other story.