Hi Lester,
On 7 February 2014 05:17, Lester Caine <[email protected]> wrote:
> Pádraic Brady wrote:
>> 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.
>
> No his hack attempt assumes that a reply happens in a certain time, this
> 'fix' is designed to make the response time consistent to prevent a timed
> attack, while I am saying that I would actually have blocked the account
> after 10 attempts, but that I would delay responding up until that limit.
> Some sites simply block at three failed attempts, but that is too quick? Yes
> the DOS attacks then become a problem, blocking accounts, but that is a
> different problem. If your site is vulnerable to a 'timed attack' then
> something else is wrong?
You’re mixing up two different attack scenarios I think. When you
introduce delays and account locking, you’re defending against a brute
force attack. A strong secret is really hard to guess. If you take a
secret of length 20 using only alphanumerics and no spaces, the
implied number of possible matches is 36^20. That’s a really huge
number of requests. Throw in time delays and lockouts, and a brute
force attack of that scale is…let’s call it hard.
If you instead use a timing attack, the number of requests needed
(assuming zero random noise) would be 36*20 which is 720 requests.
Let’s say each takes 2 secs and encounters a programmed delay of 3
secs on average and you can’t parallel the task for mysterious
reasons. That’s (720*2*3) 3,600 seconds or 1 hour. Even worse, actual
success rates will probably average this to 50% or 30 minutes. If you
lock the account, you might do it for 10 mins on every request
(because you’re really mean) which would be (720*2*600) 86,400 seconds
or 1 day (12 hours if you assume average success rates).
As you can see, a timing attack is incredibly efficient compared to
brute forcing even in a worst case scenario. You can make it more
interesting by assuming sampling needs 1000 samples per attempted
character guess. That would get it to 500 days and keep any one users
account locked down indefinitely. Of course, the server would likely
not be sitting idle for the 10 minute lockout and there would probably
be >1 server :P. So you actually just managed to publish a DDOS target
on your back.
> different problem. If your site is vulnerable to a 'timed attack' then
> something else is wrong?
No, nothing else is wrong. Being vulnerable to a timing attack has a
separate mitigation to brute forcing attacks. They are mutually
exclusive vulnerabilities.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
Patrick Brady, ACA, Fund Accounts
Mercer | Charlotte House, Charlemont Street , Dublin 2, Ireland
+353 1 6039838 | [email protected]
www.mercer.com | Mercer (Ireland) Limited