November 6, 2017 By David Bryan 3 min read

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

Stealthy WailingCrab Malware misuses MQTT Messaging Protocol

14 min read - This article was made possible thanks to the hard work of writer Charlotte Hammond and contributions from Ole Villadsen and Kat Metrick. IBM X-Force researchers have been tracking developments to the WailingCrab malware family, in particular, those relating to its C2 communication mechanisms, which include misusing the Internet-of-Things (IoT) messaging protocol MQTT. WailingCrab, also known as WikiLoader, is a sophisticated, multi-component malware delivered almost exclusively by an initial access broker that X-Force tracks as Hive0133, which overlaps with TA544. WailingCrab…

Empowering cybersecurity leadership: Strategies for effective Board engagement

4 min read - With the increased regulation surrounding cyberattacks, more and more executives are seeing these attacks for what they are - serious threats to business operations, profitability and business survivability. But what about the Board of Directors? Are they getting all the information they need? Are they aware of your organization’s cybersecurity initiatives? Do they understand why those initiatives matter? Maybe not. According to Harvard Business Review, only 47% of board members regularly engage with their CISO. There appears to be a…

GootBot – Gootloader’s new approach to post-exploitation

8 min read - IBM X-Force discovered a new variant of Gootloader — the "GootBot" implant — which facilitates stealthy lateral movement and makes detection and blocking of Gootloader campaigns more difficult within enterprise environments. X-Force observed these campaigns leveraging SEO poisoning, wagering on unsuspecting victims' search activity, which we analyze further in the blog. The Gootloader group’s introduction of their own custom bot into the late stages of their attack chain is an attempt to avoid detections when using off-the-shelf tools for C2…

Hive0051’s large scale malicious operations enabled by synchronized multi-channel DNS fluxing

12 min read - For the last year and a half, IBM X-Force has actively monitored the evolution of Hive0051’s malware capabilities. This Russian threat actor has accelerated its development efforts to support expanding operations since the onset of the Ukraine conflict. Recent analysis identified three key changes to capabilities: an improved multi-channel approach to DNS fluxing, obfuscated multi-stage scripts, and the use of fileless PowerShell variants of the Gamma malware. As of October 2023, IBM X-Force has also observed a significant increase in…

Topic updates

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