Hi Lester,
On 7 February 2014 22:10, Lester Caine <[email protected]> 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