
Salt as a Service: Interesting approach to hashing passwords - cpeterso
http://www.darthnull.org/2015/04/21/blind-hash
======
scott_karana
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.

~~~
chias
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.

~~~
scott_karana
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.

~~~
chias
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.

------
TheLoneWolfling
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.)

------
markvdb
"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...

------
PretzelPirate
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.

~~~
clinta
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](https://www.grc.com/sqrl/sqrl.htm)

------
adventured
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.

------
ademarre
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

------
mattbarrie
Works great until the remove server goes down and no-one can log in anymore.

~~~
tptacek
That's true of a lot of third party services, though.

------
ademarre
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?"_

------
mckiddy
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.

