BlindHash™ is a single click install on all major platforms, and an open source library for your favorite language. Our solution is easy to add or remove on a per-user basis.
UNDER YOUR CONTROL
Your privacy and security is our only concern. BlindHash™ knows nothing about your users; not their username, nor their password, not even if a login attempt was successful.
STILL HAVE QUESTIONS?
Click here to contact one of our BlindHashers who would be happy to walk you through a detailed explanation of the technology or visit our FAQ page.
BLINDHASH™ CYBER TECHNOLOGY OVERVIEW
Start by Hashing
Industry best practice is to secure passwords using a tunable hashing algorithm. Pick the right hashing algorithm, tune its cost factors so it runs slowly and makes optimal use of your hardware, and it’s possible to protect very strong passwords from being cracked. Slow hashing functions work by imposing a runtime cost for each guess at a password. More complex hashing translates into higher latencies for each login attempt, and a higher cost for each cracked password.
When passwords have high entropy—meaning they are truly hard to guess—then the cost of running an offline attack can become prohibitive. But when the average password is trivially easy to guess, attackers can launch an adaptive dictionary attack, and the cost of hashing also becomes trivial. Users tend to choose memorable passwords which on average are much too weak to withstand these attacks. Forcing complex password policies on users makes a huge usability trade-off, often without actually making the passwords much more difficult to crack.
Hashes are designed to be small, often just 32 bytes each, so it’s very hard to detect if they are being moved over the network, and large volumes of hashes can be moved very quickly. These are technically features, but it makes hashes far too easy to steal.
With BlindHash™ Cyber, you start by applying the hashing method of your choice, and you gain all the protection that hashing has to offer. But then instead of storing the salt and hash in your user database where it could be stolen and attacked offline, we do something a bit different.
The Data Pool
We start by creating a large pool of random, incompressible data. This data is stored in racks of solid-state drives, in secure data centers, replicated across several geographic locations, and backed up offline on encrypted tape. The data pool is sized large enough that simply trying to transfer the entire pool over the network would take years at full line rate.
Next, we’ll show how you can entangle any password hash with this massive data pool, so that an attacker trying to run an offline attack would have to first steal the vast majority of the data pool before they could crack even a single password.
A password hash can be thought of as a pseudo-random positive integer value. We can use the password hash as an index into the data pool, so that each guess at the password requires access to a different location in the pool. We make a small read (e.g. 64 bytes) from that location, and return the result. You use the result as a key, or salt, to perform further hashing on the password, before saving it to the database (when enrolling a new password), or checking if it matches the saved value (when verifying an existing password).
To step through the figure above, first the user submits user and pass. On the site’s server, the username is used to retrieve Salt1 and Hash2 from your database. You perform some hashing with Salt1 and the password to calculate H1. But instead of storing H1 in the database directly, we perform BlindHash™ on H1, which returns back Salt2. You then use Salt2 instead of Salt1 to perform additional hashing to get H2, which is finally compared to the stored Hash2 from your database. A match means the password was correct and the user is logged in.
In this manner, your hashes are blinded by the data pool such that each attempt to store or verify a password would need to be able to read the same block from the data pool to complete. An attacker would need to query the data pool separately for each guess at a single user’s password.
Even though H1 is sent to the Data Pool over a secure connection, we want to be sure that no sensitive data is leaving the site’s server. We recommend using a 64-byte secure random number for your salts, so that the hash on its own can’t be used to crack the password. If you use smaller, non-random, or public salts, a 64-byte secure random ‘pepper’ will have the same effect.