Password hashing is the process of converting a plain-text password into a fixed-length string of characters (called a hash) using a one-way cryptographic algorithm. Unlike encryption, hashing is irreversible. You’re not supposed to be able to turn a hash back into the original password. For example, a password like Password123! run through a hash function might produce something like 3d4f…9e1a (a seemingly random jumble of characters). This hash is what gets stored in the system’s database instead of the actual password.
Why do this? Storing plain-text passwords is incredibly dangerous. If attackers breach a system and find a list of users’ actual passwords, they instantly have the “keys to the kingdom” for those accounts (and potentially any other accounts where those passwords were reused). Despite this, many sites and services will still store passwords in plaintext. More importantly, you have no control over how external websites, apps, or services handle passwords, nor can you prevent your employees, users, or customers from reusing the same passwords on other, potentially less secure platforms.
Modern cybersecurity standards require passwords to be stored using strong hashing algorithms. The primary reason is to limit damage if (or when) a breach happens. A hashed password database, in theory, forces an attacker to identify each password hash rather than simply reading passwords in plain text. Thus, hashing is essential for compliance and security best practices.
To illustrate, consider the difference:
In short, hashing passwords is a fundamental security practice to protect users. But despite this, a compromised password hash should still be treated as a full compromise. Enter the rainbow table.
A rainbow table is a precomputed database of hash values mapped back to their original plaintext passwords. In simpler terms, you can think of it as a giant lookup table or “cheat sheet” for password hashes. Attackers build rainbow tables in advance by taking huge lists of candidate passwords (like common passwords, dictionary words, or all combinations up to a certain length), hashing each of them, and storing both the plaintext and the hash in the table. Later, if an attacker obtains some hashed passwords from a breached system, they can quickly look up those hashes in the rainbow table. If a hash is found in the table, it yields the original password instantly.
In essence, a rainbow table attack turns the arduous task of cracking many hashes into a simple database lookup. This makes cracking hashed passwords much faster than guessing passwords from scratch each time. Instead of hashing millions of guesses in real-time, that heavy lifting has already been done beforehand. Salting is a technique that can make it more difficult for attackers to leverage rainbow tables, but this is impossible to do in many common systems (such as Active Directory) and it shouldn’t be assumed that third parties are protecting data in this way.
In most cases, attackers don’t even need to build their own tables. Large rainbow tables for common algorithms are freely available on the internet or dark web, sometimes hundreds of gigabytes in size.
When other sites are breached, whether they store passwords in plaintext or using weak hashing, those stolen credentials often end up sold or shared online. If your users reuse the same passwords in your environment, a data leak on a third-party site can directly jeopardize your organization. Unfortunately, you can’t control how securely other sites handle passwords.
Enzoic closes this gap by providing a secure way to ensure your users are not reusing passwords that have been previously exposed, regardless of how those sites stored them. Enzoic continuously updates its database of compromised credentials from breaches around the world. By integrating Enzoic, your organization can check every new or existing password against this global breach intelligence.
Even if the third-party site stored passwords in plaintext or with hashing, Enzoic will have captured those credentials when they surface. As a result, you’ll know instantly if a user in your environment is using a password that attackers already have from a different breach, and you can block or remediate that password choice before it’s ever used in your system.
To combat the threat of compromised passwords (while preserving security and privacy), Enzoic employs an innovative approach known as partial hash comparison. This method allows organizations to check if a password exists in known breach data without ever revealing the actual password or full hash to Enzoic.
Here’s how it works in practice: Suppose a user in your organization is changing their Active Directory password, and you want to ensure this new password isn’t known to be compromised from other breaches. With Enzoic’s plugin (Enzoic for Active Directory), when the user sets the password, the plugin will hash the password. Instead of sending that entire hash to Enzoic, it will take just a portion of it. Specifically, the first 10 hex characters of the hash, and send only that substring to the Enzoic cloud API.
Why only the first 10 hex characters? This is to protect privacy. Ten hex characters (which is 40 bits of the hash) is enough to get a shortlist of possible matches, but not enough to reconstruct or identify the actual password or full hash. Enzoic’s cloud checks its extensive database of known compromised passwords for any hashes that start with those 10 characters. It then returns a list of candidate hash suffixes that match that prefix. In other words, Enzoic says, “I found some hashes in my database whose first 10 chars match what you sent and here are the rest of the hash values for those.”
Now the local plugin takes that list of candidate hashes and compares each to the full hash of the user’s actual password (which never left the local system). If there’s an exact match, it means the password is found in Enzoic’s compromised password database. At that point, the plugin can reject the password and prompt the user to choose something safer (or take whatever action is configured, such as alerting an admin). If none of the candidates match, the password is not known to be compromised and can be accepted.
This partial hash approach is a form of k-anonymity implementation; it ensures that Enzoic never learns the actual password or even the exact hash you’re checking. A potentially substantial number of passwords share the same first-10-hex prefix, and it’s virtually impossible to compute the full password from just that portion of the hash. And because the final comparison (full hash) happens on your side, the result of the check (compromised or not) is never explicitly sent back to Enzoic. Enzoic provides the data but doesn’t know which entry (if any) matched.
Crucially, this means no sensitive credential data leaves your environment. You get the benefit of Enzoic’s up-to-date compromised password knowledgebase without sharing your users’ passwords or hashes in the process. Even if someone were to intercept the communication, Enzoic encrypts data transferred across public networks using 256-bit encryption keys via HTTPS using no less than TLS 1.2. If an attacker theoretically could decrypt the communication, they would only see a hash prefix (insufficient to identify the password) and a list of hash suffixes (which are basically just data from Enzoic’s breach database, not your user’s info).
Enzoic has integrated this privacy-preserving check throughout our product portfolio. Enzoic for Active Directory, the plugin mentioned above, uses Enzoic’s APIs to perform partial hash checks whenever users set or reset passwords (and even continuously monitors existing AD passwords against newly discovered breaches). Likewise, Enzoic’s Compromised Password Screening and Compromised Credential Screening, which can be used in custom applications or workflows, utilize the same partial hash comparison mechanism for any submitted password checks. This approach is consistent across these offerings, giving security teams a safe way to automatically screen passwords against real-world compromised credentials data.
Password hashing remains important for secure authentication, but as we’ve seen, it’s not foolproof on its own. Rainbow table attacks demonstrate that hashing can be quickly undone by determined attackers, exposing user passwords in plain text. And once those passwords are known, the common habit of password reuse can turn one compromised hash into a threat to multiple systems.
Cybersecurity professionals must ensure that password hashes are as resilient as possible by using strong hashing algorithms and avoiding practices that make attackers’ jobs easier. At the same time, it’s wise to assume that passwords in your environment will become compromised through 3rd party breaches and be vulnerable to account takeover. Monitoring and defense measures should be in place to catch and respond to this.
Enzoic’s continually updated database offers one such defense: it lets you leverage a global corpus of known compromised passwords to check new or existing passwords in your environment, all while keeping user credentials secure and private. Both Enzoic for Active Directory and Enzoic’s Screening or Monitoring services employ partial hash comparisons, a practical way to mitigate the risk without exposing sensitive data. By catching compromised passwords (either in hashed or plaintext) before they’re used, and by understanding the risk of password reuse, security teams can stay one step ahead of attackers.
AUTHOR
Josh Parsons
Josh is the Product Manager at Enzoic, where he leads the development and execution of strategies to bring innovative threat intelligence solutions to market. Outside of work, he can be found at the nearest bookstore or exploring the city’s local coffee scene.
Explore free for up to 20 users. Save hours of admin time and simply get started with a password monitoring solution.