theDocumentId => 1340928 Hashes, Salts, and Rainbow Tables: Confessions of a ...

Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

5/12/2021
01:00 PM
Keira Stevens
Keira Stevens
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Hashes, Salts, and Rainbow Tables: Confessions of a Password Cracker

Understanding a few basics about how password crackers think and behave could help you keep your users safer.

If you've ever watched TV and movies about cybersecurity, you probably envision someone sitting in a dark room trying to guess someone else's password based on a few facts like their kids' names or favorite sports team. 

Even Mr. Robot, renowned for its realistic portrayal of technology, is guilty of showing password cracking this way

While targeted attacks on individuals using personal information and social engineering do happen, they are not the norm. These portrayals might give people a false sense of security because they don't think their accounts are valuable or they would get locked after a few wrong guesses.

Related Content:

Farewell, Dear Password? The Future of Identity and Authorization

Special Report: Assessing Cybersecurity Risk in Today's Enterprises

New From The Edge: Planning Our Passwordless Future

In reality, cybercriminals generally aren't guessing passwords for one person, and accounts do get locked after inputting the wrong password. That wouldn't be a very effective or efficient way to break into enough accounts to make a substantial profit. 

Once a site has been breached, threat actors often share the leaked users' files from that site. The file typically contains each line in the database associated with a user — e.g., email, username, password_hash, etc. The leaks to many sites, large and small, are posted on hacking forums where other criminals and ethical security researchers race to analyze and crack the hashes in the file.  

A hash is a representation of the password created after running it through a hashing algorithm. There are a variety of these algorithms (including SHA1, MD5, and Bcrypt), and they vary in their complexity. When the password "123456" is hashed, it may be stored as "e10adc3949ba59abbe56e057f20f883e." Every unique password has a unique hash, but each algorithm converts each password to the same hash, assuming it's not salted. In other words, "123456" will always be hashed as "e10adc3949ba59abbe56e057f20f883e" with MD5.

Sometimes this gets explained as encryption, but encryption works in two directions — encryption and decryption. If you know the cipher for something that is encrypted, you can reverse it to decrypt the data. Hashes only go one direction. You can't take the hash "e10adc3949ba59abbe56e057f20f883e" and reverse the code to get back to "123456."

Instead, password cracking compares two hashes to find matches. You generate hashes using known plaintext words to see if the hash ever matches the hash that you are trying to crack. When the hash matches, you have cracked the password. 

In the early days, crackers relied on rainbow tables, which are lists of hashes and associated plaintext passwords. If they knew a hash and wanted to see the associated password, they simply compared the known hashes in their rainbow table with hashes in the database to find matches. But rainbow tables are incredibly large and require a lot of hard drive space. 

One tactic companies use to deter rainbow table attacks is to add additional characters, called a salt, to the beginning or end of the password before it gets hashed. The salt is typically unique to each user, so if two people on that site have the same password, their salts would be different, resulting in different hashes. 

In addition to salts, there are also peppers, a random bit of data added to the password before it gets hashed. Unlike salts, peppers are not stored in the database with the hash. They are hardcoded into the website's source code. 

Even with salts and peppers, passwords can be cracked. Password crackers' success often comes down to time and computing power. Nearly any password, regardless how long or complex, can be cracked with enough time and processing strength. 

In its infancy, password cracking worked like I explained above. Password crackers used CPUs to mathematically generate possible hashes. Or they'd match known hashes to the passwords on the rainbow table.

Today, brute force attacks are more common. Crackers use GPUs, which are often associated with gamers and cryptocurrency miners because, while they can't do complicated math, they can run simple calculations on a large scale. A CPU can do complex calculations very fast but is limited by cores and threads. A GPU has thousands of less complex cores or mini-processors that can generate a hash very quickly. Where a CPU could guess 20,000 combinations per second, a GPU can do 6 million per second. 

In a brute-force attack, the cracker would use the GPU to run all the combinations of letters, numbers, and characters until it figures out the right one. Even with a salt making it more difficult, a GPU with enough time will crack it if the salt is known.

If you started reading with the idea that your password is solid and unbreakable, I hope that you have a more realistic opinion now. No one can predict when an attacker might steal data from a site where you have an account. The best thing you can do is be ready for when it does — and it is a matter of when, not if. Protect yourself with unique passwords at least 16 characters and a combination of letters, numbers, and symbols for each account, and keep track of your logins in a password manager. And when you find out a site that you use has been breached, take it seriously and change your password immediately. 

Keira Stevens is manager of the Human Intelligence (HUMINT) team at SpyCloud. For over 10 years, she has worked in information security on both red and blue teams and assisting law enforcement to identify criminals. Password cracking is a hobby and passion for Keira, as well ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-23416
PUBLISHED: 2021-07-28
This affects all versions of package curly-bracket-parser. When used as a template library, it does not properly sanitize the user input.
CVE-2021-23417
PUBLISHED: 2021-07-28
All versions of package deepmergefn are vulnerable to Prototype Pollution via deepMerge function.
CVE-2021-23415
PUBLISHED: 2021-07-28
This affects the package elFinder.AspNet before 1.1.1. The user-controlled file name is not properly sanitized before it is used to create a file system path.
CVE-2020-4974
PUBLISHED: 2021-07-28
IBM Jazz Foundation products are vulnerable to server side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 192434.
CVE-2020-5004
PUBLISHED: 2021-07-28
IBM Jazz Foundation products are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 192957.