I've been reading some literature on security, specifically password security/encryption, and there's been one thing that I've been wondering: is the 3-strike rule a perfect solution to password security? That is, if the number of password attempts is limited to some small number, after which all authentication requests will not be honored, will that not protect users from intrusion? I realize gaining access or control over something doesn't always mean going through the authentication system, but doesn't this feature make dictionary/brute-force attacks obsolete? Is there something I'm missing?


2 Answers 2


Yes, it will make dictionary attacks impossible through the login mechanism. (That doesn't mean much if they obtain access to the database, though. For security there you'll need to properly hash and salt the passwords.)

It also allows the possibility of a DOS attack against a certain user. Let's say I wanted to prevent you from logging in. All I'd have to do is run three bogus login attempts against your account, and then do it again every time you do whatever's necessary to reset the login. Dealing with that issue is a bit trickier.

  • 1
    Thanks! Out of curiosity, what would be an approach to dealing with the latter problem you described? For a real-world example, tons of online forums use the public username as the login id (as opposed to an email attached to the acct or something else), which means I can see what every single user is using to login with. What's to prevent me from locking every single user out of their account? A good administrator? It seems like it would be trivially easy to lock every single user out of the site.
    – prelic
    Apr 6, 2012 at 16:30
  • @prelic: Well, to deal with that problem, I'd implement something like "if a certain IP address makes too many invalid login attempts, block them." That'll stop the scenario you mentioned, but it won't deal with a serious hack attempt like a botnet. For that you need heavier security. Apr 6, 2012 at 16:43
  • 4
    The usual solution is to bound the rate of attempts coming for a given user from a fixed ip to say 5 per minute. It is not perfect but usually you do not create problems to other users, unless you happen to be behind the same proxy
    – Andrea
    Apr 6, 2012 at 16:49
  • Another approach is to present a captcha after 2 failed login attempts from the same IP - but then, a determined attacker can just rent a captcha-breaking mechanical turk for this purpose, plus it is pretty hard to find a good captcha that actually keeps machines out.
    – tdammers
    Apr 6, 2012 at 17:17

I also agree that it makes dictionary attacks less effective as ways to gain access to an account without the proper authority. However:

  • This approach could turn a dictionary attack into a DOS attack against the system preventing access if implemented poorly. For example, a server could be flooded with authentication attempts. One way around this is to have the authenticating service control the flow of subsequent accesses to a locked-out account. For example, if an account is locked out, present a delay before each subsequent login attempt. One could put a delay between a login attempt and an `access denied', however, that keeps the door open to a distributed denial of service attack where an attacker launches many simultaneous authentication attempts.

  • As was mentioned in the other answer, this could also turn a dictionary attack into a crude DOS against the legitimate owner of the account being attacked. Ways to mitigate the impact to the legitimate owner include:

    • Slowing down a run on usernames by providing no clues on whether it's the username or the password that is wrong. This makes attacks where the culprit is guessing usernames more visible to administrators and less effective.
    • Instead of locking down an account after a fixed number of failed attempts, merely lock out that mode of authentication. In other words, require a user who's account is being attacked to authenticate using a different (possibly more involved, but less easily attacked) method. A good example is how an Android phone will require a user to use their Google Login information after failing to authenticate using a screen unlock pattern or PIN. In theory, this is sort of like requiring an attacked user to ask for their account to be unlocked, however, it requires no immediate intervention from a system administrator.
    • Instead of locking down an account (or in addition to locking down an account, for this particular mode of authentication--see above) lock down attempts to authenticate from the location where the attack is originating. For example, if the authentication is done via a username and password, over the network, after three failed authentication attempts you could prevent further attempts from users from the same IP or subnet from logging in with a username or password. Where there is a good chance that multiple users (including the attacker) could be using the same IP or subnet, you could merely disable username/password authentication for the IP or subnet for a period of time, leaving more involved authentication methods open for innocent users in proximity to the attacker.
  • If your fear is inadvertently penalizing a forgetful user as if they were an attacker, instead of controlling the flow of failed login attempts after a fixed number of failed attempts, you could use the frequency of login attempts as evidence an account is being attacked. For example, if you see 10 authentication attempts within the span of a second, you could either use one of the methods above to prevent further similar authentication attempts. Alternately, you could use this rapid flood of login attempts as a signal to start controlling the flow. This method is becoming more and more popular on forums, whereas, after a certain amount of failed login attempts from a particular IP, that IP is prevented from authenticating for a short period of time.

  • Finally, a good way of preventing a user from being repeatedly targeted by a DOS attack is by allowing him/her to reset both his/her password and username. In other words, treat both the username and password as secrets. Where the username is used elsewhere (e.g. in a forum, if the username is the user's display name), simply treat this display name as something separate. This approach is usually used by social networks where the username used in authentication is one's email address--something that can be changed, but is seldom shared--while the display name used on the site is something user-defined that may or may not be changed.

Anyway, I hope one or some combination of these approaches will come in handy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.