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!