[Plugin: Login LockDown] Appears to be broken

It locked me out.
Now I can’t login as myself either.

Hi Michael (mvandemar),

You are the developer of Login Lockdown I presume? First I saw that it wasn’t updated in years, and then I saw one of the expert developers I know using it on his own blog.

Even though that’s pretty much enough of a concrete evidence, I would still like to go ahead and ask — is it still strong and secure today as it was before? I mean, security programs always seem to require constant updates, and your does not? Just asking!

Cheers!

@mvandemar
I’m not sure what the protocol for releasing an update is, but I’d also add that it would be a good idea to get rid of the ‘not updated in 2 years’ banner, as that will make people pass by it (I almost did). Also, some of the security plugins and services are now using plugin-age as a metric to flag problems.

But, my question I wanted to ask…
Will this also apply to XMLRPC for remote publishing? I’d really like to turn that feature on, but don’t want this to be a weak point for hackers.
Thanks!

@aahan Krish – Sorry for the delay, I am unsure why I did not get notification of new replies to this thread. Yes, it does work fine.

@stevew928 – you are correct, I really do need to update this. As to the XMLRPC, I have never used it. However, from what I just researched it appears as if it does use wp_authenticate(), which is what my plugin overrides, so my guess is that it works with that as well. If you use XMLRPC yourself then you could test this by entering in the wrong password into your client intentionally, and then attempting to make 3 bad posts. Then go and see if you can manually log in to the normal wp-login.php page.

Hello mvandemar,
Thanks for your very useful plugin, I have been using it on all my sites for years. However recently I have noticed some problems.
On a fresh local install of wordpress when login lockdown is activated.

1. loginlockdownAdminOptions – a:5:{s:17:”max_login_retries”;…
   is created in the options table.
2. loginlockdown_db1_version is created ion the optios table
3. The table wp_lockdowns is not created
4. The table wp_login_fails is not created

Subsequent failed logins with or without real user names fail to create the two tables in my tests.

@wallyo – does the database user you are using for this local install have create table permissions on the database? Feel free to email me if you need help debugging this.

phpmyadmin export for this user is,

GRANT USAGE ON *.* TO 'wordpresDBldax'@'localhost' IDENTIFIED BY PASSWORD '- - - - -';

GRANT ALL PRIVILEGES ON 'wordpresdbldax'.* TO 'wordpresDBldax'@'localhost';

Hello mvandemar,
I have just tested this on one of my live sites by uninstalling login lockdown, deleting wp_lockdowns and wp_login_fails then reinstalling login lockdown.
The tables were recreated on activation and are registering failed login attempts as expected.
My problem must be specific to my testing server.
Apologies for wasting your time.

@wallyo – I am still be interested in knowing what the issue was if you do figure it out. Thanks.

Hello mvandemar,

Tnx for the plugin. I have same problem of WallyO. I installed plugin but there aren’t tables wp_loginfails or wp_lockdowns on my db. Atm i’m working on localhost. My wp’s version is 3.0.4.

Can you help me plz?

Edit:

i created by mysql code both tables. Now the plugin is working ?? and i’m lock for the next hour ??

ps: Same problem on 3.4.2 wp version.

I have done some troubleshooting and have found that if called directly the loginLockdown_install function does create the two database tables on my wamplite server.
The problem lies in the lines 311-315.
On my LAMP Production server this works as designed, $activatestr outputs
activate_login-lockdown/loginlockdown.php
On my WAMPlite Development server this does not work, $activatestr outputs
C:\Users\user\Documents\MySites\wordpress-site\login-lockdown.dev\wp-content\plugins\login-lockdown\loginlockdown.php
This happens because __FILE__ outputs
C:\Users\user\Documents\MySites\wordpress-site\login-lockdown.dev\wp-content\plugins\login-lockdown\loginlockdown.php
and
WP_PLUGIN_DIR . "/"
outputs
C:\Users\user\Documents\MySites\wordpress-site\login-lockdown.dev/wp-content/plugins/
I got this to work on the DEVELOPMENT server and the PRODUCTION server by replacing

if(!defined('WP_PLUGIN_DIR')){
define('WP_PLUGIN_DIR', ABSPATH . 'wp-content/plugins');
}
$activatestr = str_replace(WP_PLUGIN_DIR . "/", "activate_", __FILE__);
add_action($activatestr, 'loginLockdown_install');

with
register_activation_hook( __FILE__, 'loginLockdown_install' );
PS. Apparently register_activation_hook is only called on activation not on update. It is documented here.

Tnx Wally, i tested it with

register_activation_hook( __FILE__, 'loginLockdown_install' );

and it worked.

??