Re: little request :)

On Fri, Feb 7, 2014 at 7:32 AM, Pádraic Brady <padraic.brady@gmail.com>wrote: > Hi all, > > On 6 February 2014 23:18, Lester Caine <lester@lsces.co.uk> 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). I think he meant that the server responds immediately, but the login will fail when attempted before the imposed time-out has run its course. If the server actually sleeps for a few seconds it becomes a DoS target. > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- -- Tjerk