Re: Time Invariant String Comparison

[Andres Perera <andres.p@...>]

On Sat, Jan 25, 2014 at 7:18 AM, David Given <dg@cowlark.com> wrote:
> On 25/01/14 11:06, Rob Kendrick wrote:
>> On Fri, Jan 24, 2014 at 10:12:02PM -0800, William Ahern wrote:
> [...]
>>> Who in their right mind would allow their website authentication system to
>>> spend 5 seconds (an eternity!) hogging a CPU? Especially when you could
>>> instead mandate passwords just three or four characters longer for the same
>>> benefit and without crippling your throughput?
>>
>> Because verifying with a correct password is much faster than verifying
>> with an incorrect one.  Plus, that 5 seconds is tunable.  Want it to be
>> only a milisecond?  Fine.  You can do that, and make sure it's always a
>> milisecond, regardless of how fast computers get.
>
> Woah, woah, you're talking about two different things.
>
> William's talking about it taking 5 CPU-seconds verifying passwords.
> This is very bad because it makes the web server trivially DOSable (a
> couple of thousand simultaneous access attempts will cause the server to
> implode).

For the comparison to be fruitful, all other factors have to be equal,
that means throttling max concurrent auths.

The comment could then be, serverside KDF reduces maximum concurrent
auths in proportion to the increase of time over a single pass of the
underlying hash.

>
> You're talking about a forced delay as punishment for submitting an
> incorrect password. This is very good because it consumes no resources
> (done right) and makes the server much harder to DoS. That's a totally
> different thing.
>
> --
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
> │ "There does not now, nor will there ever, exist a programming
> │ language in which it is the least bit hard to write bad programs." ---
> │ Flon's Axiom
>