Re: little request :)

From: Date: Fri, 07 Feb 2014 11:20:08 +0000
Subject: Re: little request :)
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Pádraic Brady wrote:
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.
Now this is the sort of material that should be in the likes of the wikipedia article! At least it is worth including in the rfc as an explanation of what is being talked about. In may own case I do like to include punctuation in the password. That only affects the maths and no doubt an attacker would add that extra level in at some point. If I am dealing with a site that needs to stay secure, the genuine user has to reset their password once it's locked out, and we would be looking at why it got locked out, but that will have problems with DOS attacks continually blocking access. Many of the third party sites I access follow that procedure. Looking at my own susceptibility to this type of attack I can completely ignore PHP as the comparison is done in Firebird, so it would be that which needed hardening, but I suppose most people will be reading a record and then getting PHP to do the comparison? So it is finally starting to make sense! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Thread (42 messages)

« previous php.internals (#72373) next »