Problem: How do you store a password but make it nearly impossible to recover the plaintext in the event that the database with the password hash is compromised?

When doing software development, it’s critical to review these functions. Having good development standards for your team will ensure that people store passwords properly and avoid mistakes that may cost you a lot of time or money later on.

Don’t use symmetric key encryption to store passwords

You could use symmetric key encryption to make a password unrecoverable, but all passwords will be exposed if the encryption key is ever discovered. Furthermore, you would still need to store the encryption key someplace, and if attackers are on your systems, there’s a good chance they have the encryption key, too.

Put simply, you should never use symmetric key encryption to store passwords. It’s a really bad idea.

Listen to the podcast: ‘Cracken’ Passwords with EvilMog of IBM X-Force Red

Password hashing does not equal encryption

Is password hashing encryption? No. To ensure that you don’t make this mistake, it’s best to have the development process create strong standards.

When reviewing code, I’ve seen all kinds of modules and source code refer to password hashing as encrypting the password. This is just not true. Hashing is a one-way function designed to always produce the same results when data is passed into it. Hashing can be a cryptographic function, but it does not encrypt the data. However, it can be a way to store passwords without retaining the original text.

I recently worked on a project where I was able to gain access to a database that not only contained bcrypt hashes, but also SHA-1 hashes in the same row. Bcrypt is a solid way to protect password hashes because it takes a lot of power to brute-force them. Bcrypt uses salts by default and does multiple rounds using the password and a salt to get a hash result.

Take SHA-1 with a grain of salt

Why do we need a salt, and what is it, anyway?

Without a salt, fraudsters could quickly determine whether 300 or 3,000 users all had the same password in a data set, since the resulting hashes in the database would be exactly the same.

So let’s talk about SHA-1 a bit. While it is fast, SHA-1 has been retired and should not be used. The managers of the aforementioned project stored unsalted SHA-1 hashes in the same database as the bcrypt hashes. This means the SHA-1 hashes were much easier to crack and brute-force.

Poor password practices

Using a cracking box with four graphics processing units (GPUs), I was able to recover about 700,000 of the 1.2 million accounts involved in my project in about 12 hours. Because there wasn’t any salting on the hashes stored in the database, that fact that we recovered one account and password meant that we could likely recover passwords for many of the other accounts at the exact same time.

Of the 1.2 million accounts, I saw thousands of users that all had the exact same hash and thus the same password. I made a top 1,000 list of this data set, and even at the bottom of this list, there were still 38 accounts that all used the same password.

Of the top 1,000 users that had the same hash, the top eight breakdown goes something like this:

1. “123456” (7,777)
2. “password” (2,721)
3. “qwerty” (1,261)
4. “123456789” (1,261)
5. “12345” (1,042)
6. “abc123” (951)
7. “123123” (601)
8. “111111” (596)

Best practices for development

When doing development, you should always choose your hashing algorithms wisely and never blindly trust code that someone has checked into a GitHub code repository. Always review Open Web Application Security Project (OWASP) best practices before implementing hashing in your code. Don’t ever make up hashing or encryption functions.

At the very least, have a human analyst conduct a security test against your code. It’s better to test your security and shed light on your own vulnerabilities than to be the next victim of a headline-grabbing data leak.

Listen to the podcast: ‘Cracken’ Passwords with EvilMog of IBM X-Force Red