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

More from X-Force

Q&A with Valentina Palmiotti, aka chompie

4 min read - The Pwn2Own computer hacking contest has been around since 2007, and during that time, there has never been a female to score a full win — until now.This milestone was reached at Pwn2Own 2024 in Vancouver, where two women, Valentina Palmiotti and Emma Kirkpatrick, each secured full wins by exploiting kernel vulnerabilities in Microsoft Windows 11. Prior to this year, only Amy Burnett and Alisa Esage had competed in the contest's 17-year history, with Esage achieving a partial win in…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

Phishing kit trends and the top 10 spoofed brands of 2023

4 min read -  The 2024 IBM X-Force Threat Intelligence Index reported that phishing was one of the top initial access vectors observed last year, accounting for 30% of incidents. To carry out their phishing campaigns, attackers often use phishing kits: a collection of tools, resources and scripts that are designed and assembled to ease deployment. Each phishing kit deployment corresponds to a single phishing attack, and a kit could be redeployed many times during a phishing campaign. IBM X-Force has analyzed thousands of…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today