[Plugin: Limit Login Attempts] Login Attempt Counter not reset after successful login (5 posts)

  1. ballinascreen
    Posted 7 years ago #

    Perhaps this is by design, but following a successful login, shouldn't the login counter be reset to its start value. On my development blog what I've been finding is that after failing at least one login attempt, the additional Limit Login information is displayed as you would expect i.e.

    Error: Incorrect Username and Password
    X attempts remaining.

    However, if I now successfully log in, and then log out, when I am subsequently returned to the login screen I now see:

    X attempts remaining - surely this should reset after a successful login and not be displayed to the user unless the number of attempts left is less than the maximum allowed?

    Am I missing something - or is this behaviour by design?


  2. johanee
    Posted 7 years ago #

    This is very much by design.

    Otherwise it would be possible to attack admin for allowed retries - 1, and then log in to a normal account to reset count.

    It would be possible to keep track ofretry count for each user tried (for each IP), but that seems rather unnecessary.

  3. johanee
    Posted 7 years ago #

    Perhaps, though, it might be interesting to include a button to do a reset of retries, in the admin panel to use while testing things?

  4. ballinascreen
    Posted 7 years ago #

    Ahh - yes - I see what you mean. I had assumed the counter was stored on a per-user basis rather than globally - so that if User X logged in successfully then only User X's login counter would be reset - other users counters would be unaffected.

    As for the potential of Admin lockouts - yes, this is something which had crossed my mind also - obviously its not desirable to disable lockout limiting completely for these users, especially for these account types, at least not permanently anyway. As you suggest, perhaps a configurable option to temporarily disable login limits for Admin (or specific) users during testing would be one way around this - although not ideal I guess.

    I suppose you could always automatically email the Admin account with a one-time unique URL (once per lockout) which when accessed would reset the login limit counter for that user - thus allowing them to retry immediately (but would still require a valid login username/password to gain access). Of course, this relies on the Admin user having email access at the time.

  5. johanee
    Posted 7 years ago #

    Just to clarify regarding stored globally. Everything: retries count, lockouts, is stored for each Internet address.

    Problems with this is:
    - Admin wanting to test that it works! :) (fortunately first few lockout for IP is only 20 minutes by default..)
    - If you are extremely, extremely unlucky with a dynamic IP

    We do not really care about the case of IP legitimately locked out because they failed way too many times (4*4 times in default before the long lockout) and then unable to log in to their own account.

    Adding an additional element (an user name, chosen by attacker) to store doesn't really help much and adds storage space and complexity.

    Regarding reseting lockouts I think the available options should be enough -- any way around an enforcement mechanism is a potential weakness -- though I'm certainly open to be persuaded otherwise.

Topic Closed

This topic has been closed to new replies.

About this Topic