Login lockdown not working for existing usernames

Hi Sharon,

when the username does exist (a valid username).

Are you saying those usernames exist in your site or are they added to Instantly Lockout Specific Usernames:

Have you also enabled the following feature Instantly Lockout Invalid Usernames:?

Are these users trying to login via yoursite.com/wp-login.php or yoursite.com/wp-admin.php?

Regards

The usernames exist on our site. They are legitimate usernames. (It’s easy to guess an actual username from the author of a post because our usernames are usually firstnamelastname.)

Yes, I have enabled the feature to lockout invalid usernames. This works perfectly.

I assume they are logging in at oursite.com/wp-login.php. I’m not aware of any other public login page. I checked oursite.com/wp-admin.php and it results in “page not found”.

I also have your plugin installed at another website. I just tested the lockdown for a valid username there, and the lockout did work when I reached the maximum number of retries for the password. So it looks like it’s a problem unique to one of my sites. I don’t know if this matters, but we have a Captcha on the login page /wp-login.php at the site where the lockdown is not working. This is the URL: https://www.napo-gpc.org/blog/wp-login.php

Hi,

I also have your plugin installed at another website. I just tested the lockdown for a valid username there, and the lockout did work when I reached the maximum number of retries for the password

What is the difference between both sites? For example: What plugins they both have? What theme are they using? Do you rung a cache plugin in both sites?

Is the site that is not working, a membership site? Or are you simply allowing users to register?

Regards

The sites are running different themes and have different plugins installed. Neither site is using a caching plugin. Do you really need a list of all the plugins? I could test with the plugins disabled on the site where the lockdown for exceeding number of failed login attempts is not working.

Both sites have member accounts. The site where lockdown is not working does not allow users to register.

Does the version of PHP matter? The site where lockdown is not working is on an old version of PHP – PHP 5.2.17, required by other non-WordPress older custom PHP pages on the site. But these pages are outside of WordPress. Does your plugin required a certain version of PHP to function properly?

Hi,

I could test with the plugins disabled on the site where the lockdown for exceeding number of failed login attempts is not working.

Yes, please try the above. If it works when all plugins are disabled then you know there is a plugin conflict. If that is the case, start enabling one by one and at the same time carrying out a test until you find the conflicting plugin.

The site where lockdown is not working is on an old version of PHP – PHP 5.2.17

You should be running minimum PHP version 5.6.xx or 7. Your version 5.2.17 is no longer supported. You can read more about it from the following documentation.

Does your plugin required a certain version of PHP to function properly?

As far as I know the developers have not added the minimum PHP requirements. However your PHP version is no longer updated and WordPress 4.9.6 functions better with PHP 7. Although you can still use PHP 5.6.xx, which the security support is still maintained for a few more months.

Let me know if the above helps you.

Kind regards

Hi @sharon9923,
Is the login page hidden on the site where you are experiencing the lockdown issues?

When you say you tested this and you weren’t getting locked out, did you by any chance have the “Login Lockdown IP Whitelist Settings” feature active and your IP address configured in those settings?

No, the login page is not hidden. It’s here: https://www.napo-gpc.org/blog/wp-login.php

No, I am not using the “Enable IP Whitelisting” setting because new accounts are periodically created and there are many accounts – it would be too difficult to keep adding accounts there.

Also note that I have gotten locked out if I mis-typed my username. The lockout does work for usernames not on the system. It doesn’t work for existing usernames that enter the wrong password more times than allowed in the retry time period.

I could test with the plugins disabled on the site where the lockdown for exceeding number of failed login attempts is not working

Did you try doing that test to rule out a possible conflict from another plugin/theme?

I plan to do this but need to do it late at night when people are not using the website. Hopefully by next week I’ll have an answer about plugins or theme conflict.

Late tonight I disabled the plugins and changed the theme to a standard WordPress theme – twentyfifteen. Then I logged out and tested trying to login with a valid username but the wrong password. The lockout was set to 3 failed logins in 4 minutes but even after 4 failed logins there was no lockout. So it’s not the plugins or the theme.

Unfortunately I have to keep the site now on PHP 5.2.17 obviously not for WordPress, but for non-WordPress pages of the website that are old custom PHP and will not run on PHP 5.4 or higher. We are working on a new website but in the meanwhile I can’t upgrade PHP, but I could change php.ini settings if there are some requirements for the security plugin lockdown to work. I wonder why the lockdown does work when I enter an invalid username, but not when it needs to count the login retries for a valid username.

Hi @sharon9923,
I have attempted repeatedly to reproduce this on a couple of my sites but I haven’t been able to.
If you would like for me to personally log into your site to try and fix this for you, I offer a premium support service.
Please contact me via my website contact page (click on my profile).

Update: after investigations on a site which was having this issue it was found that there was a discrepancy between the timestamps generated via the PHP function current_time( ‘mysql’ ) and the MySQL now() function.

I have updated the code to prevent this. The update was added to the recent release of the plugin and I am therefore setting this to resolved.