Hi all,
On 6 February 2014 23:18, Lester Caine <[email protected]> wrote:
> Yasuo Ohgaki wrote:
>>
>> Timing attack can be used to guess hash itself, one by one.
>> There are many use cases that may be attacked by timing. e.g. API key
>> This way, unbreakable random hash may be broken relatively easy.
>
>
> What I am missing Yasuo is a practical example of how this can be actioned
> as my normal methods would simply delay any following attempt to use a hash
> after a few failed attempts. That should be normal practice to block a hack
> attempt?
I can run a server indefinitely. So can an attacker. What you're
saying is that a time delay is added to lock an account. If you
compare that to a timing attack requiring 1000 requests (assumed) with
a 3 second inter-request delay from your measure, you end up with a
total execution time of one hour (approx). For a 60 byte password
hash, that's 60 hours. I could throw it at a cloud server and let it
rip. Heck, I could let it rip for a whole month to get a really
incredible sample for analysis. Afterall, if I'm going to hack a
heating system to get to a POS terminal inside Target, I probably can
write code ;).
Time delays assume the attacker lacks the computational resources and
determination needed to absorb the delay.
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative