Login Security Solution
[resolved] Forced password reset didn't allow user back in (4 posts)

  1. Andrew Wilder
    Posted 3 years ago #

    We just got the "Potential Intrusion" email after 173 failed login attempts. Our legitimate user had been logged in and was replying to comments, and she was abruptly logged out. When she tried to log back in, it forced her to reset her password.

    However, after resetting her password, she was booted out again, and ended up in a loop of having to reset her password.

    I changed the "Match Time" setting from 120 to 1 and she was able to reset her password and successfully log in again.

    It almost seems like LSS was thinking she was the attacker -- even though she obviously wasn't.

    One idea: I've recently changed our varnish cache settings, and it may strip some cookies. Does LSS look at any cookies for logged in users?



  2. Andrew Wilder
    Posted 3 years ago #

    I just looked through the <prefix>login_security_solution_fail table and, to my surprise, found only ONE entry for the particular username that was getting locked out -- and it was from six days ago.

    So now I'm really scratching my head as to why our users was locked out at all, and why she couldn't get back in after resetting her password. Any ideas?

    Thanks again,

  3. Andrew Wilder
    Posted 3 years ago #

    This just happened to us again, but with a different user. I checked the login_security_solution_fail table, and found his username listed only once today.

    After he followed the steps to reset his password, he was still unable to log in. He was just asked to reset his password again.

    As a workaround, I temporarily changed the "Match Time" back down to 5 minutes, so he could reset his password and the system would let him in.

    Any body know how to fix this?


  4. Andrew Wilder
    Posted 3 years ago #

    Quick followup for anyone who may come across this issue/thread in the future - I emailed Dan and he pointed me to step #2 in the installation instructions... Turns out that was our problem; we are running Varnish Cache, so all the requests to the server appeared to be coming from our own IP address, thus triggering the brute force attacks.

    The solution is to add this to your VCL file:

    sub vcl_recv {
    	remove req.http.X-Forwarded-For;
            set req.http.X-Forwarded-For = client.ip;

    And then to add this to your wp-config.php file:

    $_SERVER['REMOTE_ADDR'] = preg_replace('/^([^,]+).*$/', '\1',$_SERVER['HTTP_X_FORWARDED_FOR']);

Topic Closed

This topic has been closed to new replies.

About this Plugin

  • Login Security Solution
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic


No tags yet.