Precisely! We monitor the network traffic very closely. The only data over the wire is API requests/responses which are counted. Every 5 minutes we compare that against the actual number of requests performed according to the application counters. If the traffic doesn't line up, it pages the whole ops team.
Every day we are looking at total network egress. It would take an attacker over 200 days to move the data pool at full line rate. It gives us time to detect and remediate the inevitable breaches without ever exposing any passwords to an attack.
The best part is we don't see the login, we don't see the password, we just see the hash. And without the salt it's just a random number. We don't even know if the login is valid or invalid, and there's nothing we could do to make an invalid login appear valid. So our customers effectively retain full control over their authentication process.
The hash determines where we read from the data pool. 64 bytes read from each of 64 uniformly distributed locations. The 4K result is hashed and the digest is sent back in the response.
On the customer side, they use the response to run one HMAC and save the result (we call it Hash2). The original hash (Hash1) can be discarded, or if you want a way to leave the service sometime in the future, encrypted using a public key with a semantically secure (non-deterministic) algorithm.
Large enterprises where we are doing pilots also tell us they like this because it defends against insider threats as well.
Is it wrong to think of you as really secure, off site salt provider? At the end of the day you are just providing a really good source secure random bytes that are stored for the user.
What is the security benefit of sending you the actual hash of the password? Why not just the hash of a unique user token?
It's important to use the password as part of the entropy so that an attacker has to make a Blind Hashing request for each attempt to crack a password versus being able to make a single request to effectively unblind it.
Every day we are looking at total network egress. It would take an attacker over 200 days to move the data pool at full line rate. It gives us time to detect and remediate the inevitable breaches without ever exposing any passwords to an attack.
The best part is we don't see the login, we don't see the password, we just see the hash. And without the salt it's just a random number. We don't even know if the login is valid or invalid, and there's nothing we could do to make an invalid login appear valid. So our customers effectively retain full control over their authentication process.
The hash determines where we read from the data pool. 64 bytes read from each of 64 uniformly distributed locations. The 4K result is hashed and the digest is sent back in the response.
On the customer side, they use the response to run one HMAC and save the result (we call it Hash2). The original hash (Hash1) can be discarded, or if you want a way to leave the service sometime in the future, encrypted using a public key with a semantically secure (non-deterministic) algorithm.
Large enterprises where we are doing pilots also tell us they like this because it defends against insider threats as well.