Support » Plugin: Login Security Solution » Feature suggestion and delay vs block rehash

  • Resolved frisco


    First, great plugin and support. Your dedication to WP values is first rate and puts you in a select group.

    1. Delay vs block rehash: I have read some but probably not all of the reasoning for delay vs block. However, here’s a twist that I haven’t seen discussed. We use New Relic for server monitoring, and it appears that if we get a wave of brute force attacks, the delays imposed by LSS cause our metrics to appear like something is broken in our network. Our automated alerts become meaningless (and when alerts become meaningless, they get ignored), and our pretty graphs of fast response become really ugly. It leads to a longer than necessary discussion with clients to explain that we intentionally were being slow in some situations. I think this is a good case for at least making delay vs block a configuration option. Am I wrong?

    2. In conjunction with #1, we’d love to see the ability to auto-block banned usernames (or if no block, at least auto-delay). We’re banning certain usernames (yeah, you can guess which ones), and these usernames account for a very high percentage of our LSS fails. We’d love a way to enter a list of usernames and just have them blocked, with 1 entry in the fail table for the block. We’ve seen hundreds of entries for the same username and IP, and it makes it harder to extract useful information from the fail table.

    And for others interested in a big reason why this is a great plugin: on a network, it puts the plugin admin in the hands of super admins and the fail table is for the entire network. The Limit Login Attempts plugin puts settings in the hands of site admins and stores failed logins on a per-blog basis. That setup takes away a big benefit for having a network in the first place, so props to LSS and its author for doing it right.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Daniel Convissor


    Hey Frisco:

    Your monitoring software shouldn’t be experiencing slowdowns.

    The slowdowns only impact login attempts. Is the monitor trying to log in? Is it sending auth cookies? Is it doing so using IP addresses (perhaps due to proxies for your servers) or user names that the attackers are using?

    Thanks for the kinds words.


    Perhaps I mis-communicated something. It’s not that my monitoring software is experiencing slowdowns. It is observing the slowdown imposed by LSS on a failed login.

    New Relic supports very deep tracking, so it sees that wp-login.php is slow compared to another script, say single.php. If I drill a little deeper, I can see that login is slow for the sites getting login fails from LSS. In other words, New Relic isn’t tracking WHY it is slow, only that it is slow, and that’s showing up in our data. As I said, the slowness has a reason, namely that LSS imposed it, but the slowness distorts things. There may be a way in New Relic to get an overview excluding wp-login.php and base alerts on that filtered metric, but I haven’t had time to explore that yet. FYI, you can get a free New Relic account for 14 days if you have your own server/VPS and see what I’m talking about.

    On a separate note, even though New Relic is observing the LSS-imposed slowdowns, the times reported in my LSS fails table don’t take into account those slowdowns. In other words, in 1 example, I have several hundred failed attempts from the same IP, all of which are about 15-16 seconds apart. I am guessing LSS is recording the start time of this event in date_failed, not the end time. With so many fails, the end time would be much, much later, which is consistent with what New Relic is reporting. If that’s not the case, then something is amiss. If it is the case, some clarification in the docs or even a new field for end time in the fails table would make things more understandable.

    Any comment on auto-blocking or auto-slowing down banned usernames? I suppose with LSS limits set low enough, the only benefit of this is that it imposes the delay/block sooner. It allows an admin to give a little more leeway to legitimate but forgetful users while clamping down on the bulk of the bad login attempts.

    Plugin Author Daniel Convissor


    Hi Frisco:

    LSS is operating the way I feel is optimal. Having the monitoring software filter out wp-login.php is the way to go here.

    The 15 second apart thing has to do with the attacks being made by automated software that can run multiple threads and/or abort and retry if the reply is not timely.

    I have no plans to create a blacklists, sorry.

    Thanks for the feedback,


    Thanks for the reply, Dan, but…

    1) I’m not sure New Relic can filter out wp-login.php. That doesn’t necessarily mean your approach is bad, just that it is a strike against it.

    2) I am a little puzzled by this statement:

    The 15 second apart thing has to do with the attacks being made by automated software that can run multiple threads and/or abort and retry if the reply is not timely.

    If you believe that automated software can a) run multiple threads and b) abort & retry if the reply is not timely, doesn’t that effectively circumvent the delayed response on which LSS is based? Based on the attacks we’ve seen, this type of attack is the norm, not the exception.

    Plugin Author Daniel Convissor


    As mentioned in other threads, think about how many requests per second your server can handle. Hundreds, perhaps thousands. But with Login Security Solution, those bots can only get off a few requests per minute.

    To clarify then, the LSS settings work against bots that don’t do abort/retry, and for those bots that do use abort/retry, their requests per minute is based on how quickly they cycle, which in my logs showed bots retrying every 15 seconds, or 4 requests per minute.

    I agree that 4 RPM is less than the server’s potential so that LSS slows them down compared to no solution whatsoever. But that sounds like “better than nothing”. For the future, please think about ways to more effectively reduce the requests from abort/retry bots (or any bot that can circumvent LSS settings); I think your plugin will be better for it.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Feature suggestion and delay vs block rehash’ is closed to new replies.