Pádraic Brady wrote:
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.