It Seems Obvious To Me….



If you listen to IT Security experts, they will regularly tell you to make your passwords difficult to guess. They will also tell you ensure it is not short, and has a mixture of alphabetic, numeric & special characters in it – and certainly don't use a word that is found in the dictionary.

Why do we do that? Because it is important that your password cannot be easily be guessed, especially using brute force. What does that mean? It means the bad guys can automate a system to make repeated attempts to log in with your username, trying one combination of characters to form your password after another until they stumble across your password & get into your account. This may take hundreds of thousands (or millions) of attempts before the right password is submitted. But depending on the attacking system and and their target, they could make hundreds (or more) attempts at the password per second.

So the theory is – the longer the password, the more obscure the word (or combination of words) used, the use of both lower & upper case, along with special characters, the more difficult it is for a bad guy to generate the right combination to match your password. And this is all good good advice. It certainly makes it much more difficult for the bad guys.

But I can't help wonder why we allow brute force attacks to work at all. Instead of a system instantly returning with a negative response if the password is incorrect, why not build a delay into the response of say, a tenth of a second? Then, when another log in attempt is name on that same username, the response comes back after a tenth of a second delay. The next failed log in attempt on the username would result in a two tenths delay, then three tenths, etcetera. After one hundred attempts, there would be a ten second delay between responses. By the one thousandth attempt, the delay would be one hundred seconds. This would render a brute force attack useless. But a legitimate user who happened to enter the wrong password would not notice a tenth of a second delay. Even a two thenths or three tenths of a second delay.

So why aren't delays like this built into log in screens? I don't know why.

OK, OK. I'm sure some people will come back to me & say that it's not technically possible to do something like that on some systems. And I'm sure that's probably true. But I'm also sure there are plenty of systems out there that could be modified to do something like this. It seems logical to me.

Now, even if this was done wherever possible, you still need to use strong passwords. Words that are found in a dictionary are not a good idea, and using family or pet names is certainly not good practice. So you would still need to use strong passwords, but the bad guys would have less chance of cracking your password through repeated, rapid brute force attacks.


Craig Johnston
Senior Cybercrime Research Analyst



Author , ESET

  • mb

    Craig, I fear that your account has been hacked.  Certainly, nobody with a title of SENIOR cyber ra would ever make such an inane and worthless post as this.  Are  you drunk?

    • cjohnston

      MB, I’m not sure exactly what your issue is with my post. I was simply making an observation that many systems that could relatively easily implement measures to make brute force attacks more difficult don’t seem to have those measures in place. I wasn’t claiming this was a ground breaking revelation, simply an observation. Maybe I should have made it more clear that I acknowledge that there are some systems out there that already have these measures in place. I’d just like to see such measures more widely implemented where possible.

  • Ralf Muschall

    Something like this is probably implemented in places where it works (i.e. closed shops with only a few users).  On public systems (i.e. free web mail providers) it would not help – the attacker simply would loop over username-password-pairs, never getting hit by the delay (what he usually wants is an account, not the account).  The attacker could even accept the delay and try a few thousand other users in the mean time if he really is interested in a preselected set of accounts.  In addition, this could be used to run a DOS against selected users (just try trivial passwords until the delay is long enough to be perceived as "broken" by humans but still no problem for machines (delay=n*tau with n=number of trials, tau=e.g. 0.1s, totaltime=n^2/2*tau.  If the bad guy wants to reach delay=1 minute, he needs n=600, taking totaltime=5 hours, which is trivial for a bot and deadly for the user)).

  • Joe

    IBM Lotus Notes has been doing this for years.

    • cjohnston

      Good point, Joe. As I said in reply to a few comments, I’m not saying that this is not done at all, my point was that it’s not done enough. Maybe I should have made that more clear in my blog entry…. Thanks for pointing that out! :-)

  • andy

    Hi, you got very interesting ideas,  but isn't it too easy to work around for attacker?  because, if I am a attacker, I would brute force for not just one ID at a time,  I would use few hundred IDs and dictionary to match with round-robin fashion then the system you suggested will think it new ID every time so there is no chance to give delay time..

    • cjohnston

      Yes Andy, there may be a way around my suggestion. I’m not suggesting it is a perfect solution, or even a new solution. Some systems already do things like this, but many don’t that could. As for getting around it, yes you are right. But just about every security solution may be gotten around given enough time, effort & resources. But the harder we make things for the bad guys, at every step along the way, the better!

  • Lee

    on the surface, that sounds like a great idea. whether it's technically possible, or whether there arleady exists such a technique…I don't know.
    get it patented quick :-)

    • cjohnston

      Thanks, Lee. There are systems out there that already do something like this, or lock out the account after a set number of failed attempts. So I think the patent application might just fail… :-) But my point here was that there seems to be plenty of systems that COULD implement something like this, but DON’T. And I think in certain circumstances it could be a relatively easy & effective measure against brute force attacks.

  • Martin Ma?ok

    It is not so easy to implement mandatory delays without implementing a feature that can be abused to DoS particular account at the same time. From this point of view, it may be much more easier to accept the DoS risk and implement simple account lockouts after several bad login attempts…

    • cjohnston

      Agreed, Martin. That is another option that may be implemented in some cases.

  • Bob

    Why not a system where the individual can opt to insert a delay of their choice, say 1 sec, 2sec, or 5 sec, etc. between log-in attempts? I for one would be willing to wait a couple of seconds between failed log-in’s in the name of better security. That would not be a burden to me for the few times I hit a wrong key during log-in. It seems that this would be more technically feasible than implementing a incrementally increasing delay. And it would be up to the individual as to how much delay, if any, they were willing to live with.

    • cjohnston

      Good suggestion, Bob. Of course, the exact implementation would depend on the application & user base. Some systems already use measures such as this.

  • Zack

    I always begin my passwords with a special character so if an attacker uses brute force password guessing they will have to include the special character set. Which increases the required cracking time exponentially. Especially if their brute force app starts with letters, then adds numbers, then adds special characters. Basically if they're going to try and crack my password, I'm going to make them work for it! Haha

    • Randy Abrams

      Length is extremely important. A 25 character password that is all lower case will take a lot longer to brute force than a 10 character password with all of the character sets.

    • cjohnston

      Exactly, Zack. If you make it difficult for the bad guys, chances are they’ll go for the “low hanging fruit” – the easier passwords to guess/crack and move on from yours to someone else’s user account.

  • Bob

    Regarding my previous post about a user set delay, I can picture this setting being built into the BIOS and then the BIOS locked. And if we are thinking more creatively, another possibility would be to synchronize the log on with a “dongle” like PayPal uses for their log-on such that to log on to my computer I would need to enter my password + the digits in the Dongle. Maybe overkill, but without the Dongle, cracking the password would be useless. Of course this would have to be supported by the computer manufactures.

  • Tetranitro

    I was under the impression that brute force attacks were performed on password/login database files that had been stolen, locally? In other words, the bad guy uses an exploit of some sort (or social engineering, the human exploit) to grab the password database – Then uses brute force to crack the salted contents of that database?
    Now that I think about it, I don't know exactly how an attacked would know they got it 'right' under those circumstances (unless they compare to a known password).

  • David

    Why waste resources doing this?  Surely after 5 or even 10 failed attempts, lock the account for 20 mins…  If you're really concerned, use simple trend analysis or login thresholds to look for vexatious attempts and then apply a lock that requires manual unlocking.
    Considering that any normal (or other) person would take at least a second to retype their password in again, this could also be used to detect a brute force attack that retries in milliseconds.  Set a rule, if there's more than 2 (or 3) attempts in a second second, lock out the account… 
    Using counters and timers just seem to be resource hungry and as already pointed out, can lead to an unintended DoS attacks.

  • David Harley

    @Marijus, I’m afraid we can’t offer product support through the blog. Please go to the Support tab on the ESET home page.

Follow us

Copyright © 2017 ESET, All Rights Reserved.