Re: Time Invariant String Comparison

[Tim Hill <drtimhill@...>]

On Jan 17, 2014, at 1:05 AM, Pierre Chapuis <catwell@archlinux.us> wrote:

>>> Hmm .. careful. If the delay increases by a known algorithm then it’s
>>> useless, as the attacker can know the inserted delay (assuming he/she has
>>> access to the source code), and can simply subtract it out, thus getting
>>> back to being able to deduce the string compare time. The pseudo-delay is
>>> valid as long as care is taken with how the delay is computed (and, has
>>> been noted, the random “span” of the delay should increase as the number
>>> of failed attempts increases).
> 
>> It's not useless if it increases substantially with each failure. It'll
>> limit how quickly they can perform attacks.
> 
> Both of you reason with a model where the attacker tries passwords
> from the outside of the system, for instance by submitting a HTTP
> form. In that case you can use non-cryptographic solutions to defend
> yourself, like locking accounts after a number of failed attempts
> and sending an email to the user to unlock it.
> 
> BCrypt and friends defend you against a different threat model:
> your entire database has been stolen and the attacker is trying
> to find the plaintext password of your users (with John the Ripper
> or a similar tool). So you need both.
> 
> -- 
> Pierre Chapuis
> 
> 

But of course .. i don’t think i anywhere said that the suggestions were comprehensive. As everyone (except, apparently, Starbucks) knows, security is a complex and multi-faceted problem. Hashing passwords can help under some circumstances, but it’s not a panacea either.

—Tim