4 ms·

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

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 12y ago
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.
- deleted 12y ago
  [deleted]
- scott_karana 12y ago
  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 12y ago
    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.

chias 12y ago

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.

deleted 12y ago
[deleted]
scott_karana 12y ago
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 12y ago
  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.