Re: little request :)

Hi Lester, On 7 February 2014 22:10, Lester Caine <lester@lsces.co.uk> wrote: >>> >>> >>> 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! > > > OK all this theory is all very well, but while I have seen claims that this > is being exploited in the wild, I've not found anything that supports that > claim. The Firebird developers basically say that there is no possibility of > exploitation on their own hash comparisons and dispute that this is a > practical hack method. So what practical exploits do exist? That's the kicker with white hat research - white hats don't perform attacks in the wild and black hats aren't exactly forthcoming unless they are defacing sites as a form of political protest. Nate Lawson's work proved the viability of an attack in his research: http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/ There's a video here: http://rdist.root.org/2010/11/09/blackhat-2010-video-on-remote-timing-attacks/ Another excellent video with more practical detail: https://www.youtube.com/watch?v=ykNt8pSQFZQ In summary, it's the second improvement on remote timing attacks and it achieved an exploitable resolution against a target. That puts it into the theatre of being practically possible (which is a step up from a hypothetical maybe-if). Have there been actual attacks? I'm certain someone has tried - hackers would be stupid not to be working on it. Just don't expect them to advertise it. This gets back to one truly core problem when it comes to security: theory. In theory, I could have established a Man-In-The-Middle server between your mail server and your home computer. In practice, the NSA has created a planet wide MITM network that shocked everyone (maybe they thought Tor was a cute experiment?), and is currently sucking up too much data to warehouse. The use of the word theory can be misapplied as a comment on the possibility of a practical event occurring while suggesting the attack is therefore not worth protecting against. Timing attacks are practical. It's been proven. It's accepted as a security vulnerability (albeit grudgingly I know by those who have to fix it). It's been fixed in any number of applications already. We could wait for a hostile attack to actually happen and then actually be publicised, but why do nothing when the fix is so damn simple? :P -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative