Note that we still do notification and logging as usual. This is meant to allow you to be aware of any suspicious activity from whitelisted IPs.

I locked myself out testing this thing, what do I do?

Either wait, or:

If you know how to edit / add to PHP files you can use the IP whitelist functionality described above. You should then use the “Restore Lockouts” button on the plugin settings page and remove the whitelist function again.

If you have ftp / ssh access to the site rename the file “wp-content/plugins/limit-login-attempts/limit-login-attempts.php” to deactivate the plugin.

If you have access to the database (for example through phpMyAdmin) you can clear the limit_login_lockouts option in the wordpress options table. In a default setup this would work: “UPDATE wp_options SET option_value = ” WHERE option_name = ‘limit_login_lockouts'”

I’ve used this great plug-in for years, but sadly as of Feb 1, 2017, using WordPress 4.7.2, the plug-in crashed my entire website, including my log on page! My host disabled the plug-in and all was instantly fixed. The plug-in hasn’t been updated for five years, so it appears it’s no longer supported by the author and I suggest looking for another plug-in.

Interested in development?

Changelog

1.7.1

This version fixes a security bug in version 1.6.2 and 1.7.0. Please upgrade immediately.

“Auth cookies” are special cookies set at login that authenticating you to the system. It is how WordPress “remembers” that you are logged in between page loads.

During lockout these are supposed to be cleared, but a change in 1.6.2 broke this. It allowed an attacker to keep trying to break these cookies during a lockout.

Lockout of normal password login attempts still worked as it should, and it appears that all “auth cookie” attempts would keep getting logged.

In theory the “auth cookie” is quite resistant to brute force attack. It contains a cryptographic hash of the user password, and the difficulty to break it is not based on the password strength but instead on the cryptographic operations used and the length of the hash value. In theory it should take many many years to break this hash. As theory and practice does not always agree it is still a good idea to have working lockouts of any such attempts.

1.7.0

Added filter that allows whitelisting IP. Please use with care!!

Update to Spanish translation, thanks to Marcelo Pedra

Updated Swedish translation

Tested against WordPress 3.3.2

1.6.2

Fix bug where log would not get updated after it had been cleared

Do plugin setup in ‘init’ action

Small update to Spanish translation file, thanks to Marcelo Pedra

Tested against WordPress 3.2.1

1.6.1

(WordPress 3.0+) An invalid cookie can sometimes get sent multiple times before it gets cleared, resulting in multiple failed attempts or even a lockout from a single invalid cookie. Store the latest failed cookie to make sure we only count it as one failed attempt

Define “Text Domain” correctly

Include correct Dutch tranlation file. Thanks to Martin1 for noticing. Thanks again to Bjorn Wijers for the translation

Updated POT file for this version

Tested against WordPress 3.1-RC4

1.6.0

Happy New Year

Tested against WordPress 3.1-RC1

Plugin now requires WordPress version 2.8+. Of course you should never ever use anything but the latest version

Fixed deprecation warnings that had been piling up with the old version requirement. Thanks to Johannes Ruthenberg for the report that prompted this

Removed auth cookie admin check for version 2.7.

Make sure relevant values in $_COOKIE get cleared right away on auth cookie validation failure. There are still some problems with cookie auth handling. The lockout can trigger prematurely in rare cases, but fixing it is plugin version 2 stuff unfortunately.

Changed default time for retries to reset from 24 hours to 12 hours. The security impact is very minor and it means the warning will disappear “overnight”

Added question to FAQ (“Why not reset failed attempts on a successful login?”)