On Fri, Feb 7, 2014 at 7:32 AM, Pádraic Brady <[email protected]>wrote:
> 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).
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