It is an interesting premise. For years people have been trying to figure out a way to safely (and reliably) do a cloud system that would provide an added layer that could bring an end to the local ram/processor/gpu arms race.
That said, this:
"Finally, an attacker who compromises the blind hash service gains access to a database too large to exfiltrate"
is the type of notion you never want to bet on under any circumstance.
As far as cryptographical soundness, additional rounds of hashing don't require SaaS integration, nor do salt and peppering, and just add points of failure.
And if it's simply the delay of a remote API call that is the actual benefit, rather than a perceived remote computation delay: why not just add sleep(0.5) ;)
Lastly, if your site is at "web scale" to the point where you need to consider a dedicated hashing server... then maybe a SaaS isn't going to be price efficient anyways at that point.
The threat model that any salting procedure is dealing with is if someone has, e.g. downloaded your database (i.e. is performing an offline attack). So things like sleep(0.5) or rate-limiting become irrelevant.
So, you now have a database of 10,000 usernames, hashes and local salts. Normally you would fire up your favorite cracking program and get to work. Under this scheme, before you can start on a password, you must request its salt from a remote service which will probably cut you off after a significantly anomalous number of queries, or which itself could impose rate limiting. Basically, something like this enables things like rate-limiting even in the case of an offline attack.
note: not saying I necessarily think this is a particularly good idea, just that I think you're missing or misrepresenting its purpose.
The bit about "HTTP connections being simulated by sleep()" was just a cynical hypothesis in which users might have perceived a hardness benefit (rounds of a KDF) that was actually just latency (round trip). I'll edit my post to make that more clear.
As for the offline attack: I agree, and thought I addressed it in the first point:
Adding rounds to your already existing secure hash doesn't require any SaaS assistance. It simply requires increasing your "rounds" field.
Ah, I misunderstood your intention. That makes it clearer to me, thanks :) And I agree with you fully, in particular that this idea doesn't increase the guarantees or cryptographic assurances that you have in any real way.
Then again I could envision it as being useful if you're stuck in a particular situation in which your use of hash function is mandated by something out of your control. If I was forced to use plain SHA1 (or god help me, MD5) for handwavy legacy reasons, throwing something like this in might help me sleep better at night.
Would I ever use it? Probably not. But I think it's a cute hack that could be useful under the right (wrong?) circumstances.
How does this provide any better performance to the company using it? If anything it's doubling the work requirement because now you have to do 2 rounds of bcrypt/etc instead of 1.
"I think the biggest problem we have today, with regards to securely hashing passwords, isn’t the technology available, but the fact that sites still use the older, less secure approaches. If a site cares enough[...]"
There you have it. Today, I helped an older computer illiterate friend update her mobile phone company data online. She had forgotten her password, so I clicked "lost password". The mobile phone company sent out her password in plain text by email. Hashing? Salting? Never heard of it!
The concept quoted in the article does sound interesting though...
Centralizing your logins with inherent lack of local fallback isn't necessarily a good thing.
If you're trying to mitigate your password DB being stolen, insert canary accounts and have a passive device on the network scream bloody murder when it detects anything logging into one of the canary accounts.
Another approach is just to have the random data be local. (Have a large chunk of random data. The hash is a couple iterations of a standard password hash, but each time used as an index into the random data. You want multiple iterations as otherwise someone walking off with a relatively small section of the data can still crack many passwords.)
If you're preventing brute-force, there are better methods. For example, having the client submit a proof-of-work. (As a bonus to this, you can adjust the proof of work if you're under (D)DOS.)
I have decided that all auth should be replaced by the bitcoin blockchain.
The steps for logging into a site should be the following:
1. I generate a bitcoin address using the bitcoin client.
2. I go to foo.com where I want to log in.
3. I enter my bitcoin address into the "username" field.
4. I am then presented with a newly generated bitcoin address that foo.com created.
5. I use my bitcoin address' private key to sign a message containing the new foo.com address I was shown and send the message to the same foo.com address.
6. foo.com now verifies that it received a message from my address and that it contained the address it generated.
7. foo.com then logs me in to the profile associated with the my bitcoin address.
This idea is far from being fully thought through, but I like that I don't have to let any website store my password (salted or plain text, not that I can really trust a company to use the former) so if they get hacked, all they get are my public key and potentially the private key to a now useless bitcoin addresses the website generated (and will never reuse it). I also like this better than cert auth because I don't have to upload my public key to every website I use.
You don't need bitcoin for this at all. Just some of the crypto that bitcoin is built on.
1. Generate a random 256 bit number which is your ed25519 private key.
2. The public key is your username.
3. foo.com sends you a 256 bit nonce.
4. You sign the nonce with your private key and return the signed value to foo.com.
5. foo.com verifies the message is signed by your public key and contains the nonce they sent you.
And because ed25519 can use any value as a private key, you can create deterministic private keys. For example you can use a hash of a passphrase and the domain name to create a unique private key for that domain, and you don't have to remember a random username for each domain, just your master passphrase.
Steve Gibson is working on a login system that does this and uses QR codes so that a mobile device can be used to sign the nonce and return it to the server out of band.
https://www.grc.com/sqrl/sqrl.htm
When the service shuts down, all users will be required to go through the password recovery process, which is often weak. Come the think of it, that might be a good thought exercise for evaluating the strength of your account recovery procedure. "Imagine it becomes impossible to verify account passwords (hashes lost, 3rd-party service shut down, etc.), how would you recover? Are users in danger of being permanently locked out? Are accounts in danger of being stolen?"
Buried in all the talk of password salting, the interesting thing I see about "blind hashing" is that the blind hashing service can be viewed as a new hash function with some interesting properties:
- Implementing the hash function requires petabytes of storage
- Pre-image, second pre-image, and collision resistance depend on the quality of the random data block that defines the function
- Pre-image and second pre-image resistance depend on the function being kept secret
- The function is hard to steal because it is petabytes massive
- If the function were stolen, a pre-image attack would be a matter of searching petabytes of data
15 comments
[ 5.1 ms ] story [ 44.3 ms ] threadThat said, this:
"Finally, an attacker who compromises the blind hash service gains access to a database too large to exfiltrate"
is the type of notion you never want to bet on under any circumstance.
And if it's simply the delay of a remote API call that is the actual benefit, rather than a perceived remote computation delay: why not just add sleep(0.5) ;)
Lastly, if your site is at "web scale" to the point where you need to consider a dedicated hashing server... then maybe a SaaS isn't going to be price efficient anyways at that point.
So, you now have a database of 10,000 usernames, hashes and local salts. Normally you would fire up your favorite cracking program and get to work. Under this scheme, before you can start on a password, you must request its salt from a remote service which will probably cut you off after a significantly anomalous number of queries, or which itself could impose rate limiting. Basically, something like this enables things like rate-limiting even in the case of an offline attack.
note: not saying I necessarily think this is a particularly good idea, just that I think you're missing or misrepresenting its purpose.
As for the offline attack: I agree, and thought I addressed it in the first point:
Adding rounds to your already existing secure hash doesn't require any SaaS assistance. It simply requires increasing your "rounds" field.
Then again I could envision it as being useful if you're stuck in a particular situation in which your use of hash function is mandated by something out of your control. If I was forced to use plain SHA1 (or god help me, MD5) for handwavy legacy reasons, throwing something like this in might help me sleep better at night.
Would I ever use it? Probably not. But I think it's a cute hack that could be useful under the right (wrong?) circumstances.
The concept quoted in the article does sound interesting though...
If you're trying to mitigate your password DB being stolen, insert canary accounts and have a passive device on the network scream bloody murder when it detects anything logging into one of the canary accounts.
Another approach is just to have the random data be local. (Have a large chunk of random data. The hash is a couple iterations of a standard password hash, but each time used as an index into the random data. You want multiple iterations as otherwise someone walking off with a relatively small section of the data can still crack many passwords.)
If you're preventing brute-force, there are better methods. For example, having the client submit a proof-of-work. (As a bonus to this, you can adjust the proof of work if you're under (D)DOS.)
The steps for logging into a site should be the following:
1. I generate a bitcoin address using the bitcoin client.
2. I go to foo.com where I want to log in.
3. I enter my bitcoin address into the "username" field.
4. I am then presented with a newly generated bitcoin address that foo.com created.
5. I use my bitcoin address' private key to sign a message containing the new foo.com address I was shown and send the message to the same foo.com address.
6. foo.com now verifies that it received a message from my address and that it contained the address it generated.
7. foo.com then logs me in to the profile associated with the my bitcoin address.
This idea is far from being fully thought through, but I like that I don't have to let any website store my password (salted or plain text, not that I can really trust a company to use the former) so if they get hacked, all they get are my public key and potentially the private key to a now useless bitcoin addresses the website generated (and will never reuse it). I also like this better than cert auth because I don't have to upload my public key to every website I use.
1. Generate a random 256 bit number which is your ed25519 private key.
2. The public key is your username.
3. foo.com sends you a 256 bit nonce.
4. You sign the nonce with your private key and return the signed value to foo.com.
5. foo.com verifies the message is signed by your public key and contains the nonce they sent you.
And because ed25519 can use any value as a private key, you can create deterministic private keys. For example you can use a hash of a passphrase and the domain name to create a unique private key for that domain, and you don't have to remember a random username for each domain, just your master passphrase.
Steve Gibson is working on a login system that does this and uses QR codes so that a mobile device can be used to sign the nonce and return it to the server out of band. https://www.grc.com/sqrl/sqrl.htm
- Implementing the hash function requires petabytes of storage
- Pre-image, second pre-image, and collision resistance depend on the quality of the random data block that defines the function
- Pre-image and second pre-image resistance depend on the function being kept secret
- The function is hard to steal because it is petabytes massive
- If the function were stolen, a pre-image attack would be a matter of searching petabytes of data