Iterative password hashing functions need to be slow to be secure. Their cost factor is borne through consumption of real-time resources such as CPU cycles and

Iterative password hashing functions need to be slow to be secure. Their cost factor is borne through consumption of real-time resources such as CPU cycles and memory bandwidth, and therefore cost is roughly synonymous with latency. BlindHash is a completely different approach. I used data as a cost factor — a massive array of random data, which can grow over time but once a bit becomes part of the pool, it never changes. Here’s how it works; First, a fast hash (SHA512) and a secure salt (64 byte CSPRN) turns your password into a random number, call it Hash1. That 64 byte value is sent to a BlindHash Server. On the BlindHash server Hash1 is used to generate 64 uniformly distributed i.i.d indices into the data pool, which imagine is ~100TB of data, and you read 64 bytes from each location. Accumulate those 64 reads into a 4KB buffer, and hash that. Return that result. Back on the authentication machine, use the result from BlindHash to HMAC your Hash1 to produce a Hash2. Store/Verify the Hash2 value. Hash1 is never stored. What this accomplished is basically entangling the password hash with an arbitrarily large pool of data, where an attacker needs to steal >90% of the data pool in order to even start attempting an offline attack. The bigger you make the data pool, the more data an attacker would have to steal, but the faster the system runs — because more data spread across more SSDs increases read bandwidth since the read pattern is perfectly uniform. The network carries 64 bytes in and 64 bytes out with each BlindHash request. Size the network pipe to handle your desired authentication load, e.g. 64 * 100,000 = 6.4MB/sec. Divide the data pool by the available bandwidth, e.g. 100TB / 6.4MB = ~180 days. That’s how long it takes to steal the data pool over the network at full line rate. And the attacker needs virtually all of it to even try to start an offline attack. For large scale secure password storage, BlindHash provides the means to eliminate the possibility of an offline attack. It’s faster and cheaper than burning expensive CPU cycles, and most importantly security (growing the data pool) and performance (logins/sec) are positively correlated, not negatively. It Scales. Disclaimer: I’m the inventor, patent holder, and CTO of BlindHash, and I’ve been working on productizing this technology for several years now. As a longtime HN member/contributor I do feel like it’s OK to occasionally pitch my company when relevant topics trend on the front page, as long as there’s an interesting technical component to go along with it! If you’re responsible for securely storing customer passwords at a large corporation, scrypt/bcrypt/argon2 is not the right approach for you. You’re better off spending those cycles mining Monero. Let me help you eliminate the possibility of a breach and actually save you money in the process. You can have your own on-prem data pool, or share a massive geo-replicated pool with other large corporations at an even lower cost. </pitch>