Limit Login Attempts 1.4.1 WordPress Plugin Review

WordPress Plugin Review

WordPress Plugin Review

Plugin Name: Limit Login Attempts v.1.4.1
Date of review: 10th November 2009
Rating: 4.8
Author profile: Johan Eenfeldt
WordPress plugin directory link: Limit Login Attempts

“Limit Login Attempts” WordPress plugin limits the number of wrong login attempts possible through normal login dialog as well as (for WordPress 2.7+) for cookies authentication mechanism.

You can find the original description of this plugin at the authour’s blog plugin page. I just tell you about my impressions after testing this plugin here.

This plugin is well-made, its code is accurate, easy to read and has detailed comments inside. After testing and investigating the source code I confirm that Limit Login Attempts WordPress plugin operates exactly as declared by its author.
Just for your safety, you can be sure: Limit Login Attempts WordPress plugin is checked by me as an independent developer. This plugin has not any hidden code which make something malicious or not declared by the author in plugin description.

I didn’t meet with bugs during thorough tests I made. Johan (the author) made a good job and continues enhancing his plugin. He made 5 code change releases this year and we can add here the minor updates with translations to the different languages added. More – 2.0beta3 version is available already at
Plugin works pretty good. Thank you, Johan, for the excelent and useful plugin.

What does we have under the hood?

In comparison to the Login lockDown plugin, which was made with the same purpose, “Limit Login Attempts” plugin has some advantages/differencies:

  • In addition to the standard login dialog mechanism “Limit Login Attempts” secures with wrong retries limit the WordPress cookie authentication.
  • “Limit Login Attempts” has feature to define login IP if it sits behind the Proxi
  • “Limit Login Attempts” doesn’t create and use new MySQL tables. It uses standard WordPress wp_options table to store its data. It automatically clears invalid login attempts data after definite time period. With such realization “Limit Login Attempts” has not that imperfection in MySQL data storage and processing manner which “Login lockDown” has. But that imperfection is relative and can be fixed easy in the future version if plugin author desire to make it.
    Technically “Limit Login Attempts” stores IP data in the one option field and load it into array variable at once. In theory we can imagine situation when error can occur for the not enough memory reason: very large users quant and very large daily login attempts quant with wrong tries. As that theoretical situation can be met in real life very rare I will not take it into account in this review and in the rate value.
  • Very good thing for “Limit Login Attempts” that it doesn’t advertise itself adding special text to the WordPress Login dialog box as “Login LockDown” plugin does.
  • “Limit Login Attempts” has more convenient and flexible options set.

Not so good issues for this plugin:
First of all, concerning the security field, I repeat it again – “Silence is golden”. If you don’t know or remember why, you can read these my previous posts:

Second, When intruder exhausted invalid login attempts limit, “Limit Login Attempts” shows the special error messages:
“ERROR: Too many failed login attempts. Please try again later”, “Please try again in %d hour”, etc.
It can clearly show to intruder that this blog has “Limit Login Attempts” installation. As the blog owner I prefer to have the option to show this special messages or not. Ideally, my login dialog behaviour must be the same as WordPress default one or little different but the same for all kind of the login errors.
Third, if you try to call limit-login-attempts.php file directly from the browser,
and php error messages is not turned off on your site, you will see this error message in your browser:
PHP Fatal error: Call to undefined function load_plugin_textdomain() in …\wp-content\plugins\limit-login-attempts\limit-login-attempts.php on line 99
That is bad guy can discover your site real path. If he knows what shared hosting you use, and hosting provider has some security hole in his system, bad guy can reach your site and get it data, control it, etc. relatively easy.
I repeat, plugin author has to check if his script is called under WordPress environment and stop working if somebody tries to call it directly, as stand-alone script. For example, add this code at the beginning of every plugin:

if (!function_exists("get_option")) {
  echo 'Direct call is prohibited';

For this minor defects only I asign this plugin 4.8 rate.

Inspite of some critics, I think that this plugin is the better choice in this niche and for this time. Of course the final choice is for you. I just tried to help you in this not easy selection 🙂

Thanks for the reading,

Tags: , ,

  • Hi Vlad

    Very useful and helps me make up my mind which one to use.
    I've posted a comment on the pligin authors site so that he can read your review.

    I have very little knowledge of php, but do I have to add the code you suggest (see below) to the beginning of this plugin?

    if (!function_exists(“get_option”)) {
    echo 'Direct call is prohibited';

    Thanks for taking the time to do the review.

  • shinephp

    This code does the following:
    1) if (!function_exists(“get_option”)) {
    this line checks if core WordPress function get_option() exists. If it doesn't, then we are not inside WordPress environment (script direct call take place), so tell the caller that his action is not allowed at this line
    2) echo 'Direct call is prohibited';
    and stop script execution at this line
    3) die;

    You can add this code to the begin of the limit-login-attempt.php file if you wish to exclude ability of its direct call execution. Additionally to fully hide your use of this plugin you have to add empty index.php or index.html file into plugin directory to exclude its content listing, delete screenshot image files and readme.txt file also.

  • Thanks Vlad
    I think I can manage that.

  • Omi

    Indeed, in security matters silence is golden.

    Nice review by the way.

    How do you think about “User locker” instead this one? This plugin lock the user after XXX unsuccessfully login attemps and the account only can be unlocked by an admin.

  • shinephp

    Thanks for the occasion to make another plugin review from login security series. I will make some research with the “User-Locker” plugin source code, test it and then publish the next review.

  • Pingback: User Locker 1.1.7 WordPress Plugin Review |

  • shinephp

    User Locker 1.1.7 can not be used instead of Limit Login Attempts as they works on the different lines of your blog defence. If you are interested please read my review for User Locker 1.1.7 plugin.

  • Omi

    Sure, I'm going to read it carefully. Thank you.

  • shinephp

    User Locker 1.1.7 can not be used instead of Limit Login Attempts as they works on the different lines of your blog defence. If you are interested please read my review for User Locker 1.1.7 plugin.

  • Omi

    Sure, I'm going to read it carefully. Thank you.

  • Pingback: wordpress login()

  • Pingback: » Blog Archive » Limit Login Attempts 1.4.1 Wordpress Plugin Review |

  • Jason

    Vladimir, I need your expertise advice on this regarding Limit Login Attempts plugin…

    This is indeed a very useful handle plugin; however, the problem I’m running into is since my host required me to add a “cache-plugin” (and I’m using “Hyper Cache” btw), it no longer works!

    I’ve set the limited login to 5 before lockdown, and I tested this from the wp-admin login page; I entered the wrong credential multiple times and it stays at 4 login attempts left even though I used more than that.

    This Hyper-Cache is caching this 4th-login-try attempt…and won’t go down at all below that.

    So this “Limit Login Attempts” doesn’t protect me anymore, having this Hyper-Cache plugin.

    Would you please tell me do you know any solution to this? Of is this just the Hyper-Cache plugin that needs fixing?

  • Try to use URL rejection feature for wp-login.php
    Quote from “Hyper Cache” official page:
    “URI rejection and matching criteria:
    There are times when a page or a post has to be served always from WordPress. Given the URI (URI is the right word) of that post, it can be added to the url to reject textarea. Let’s go with an example. You have a special page that has not to be cache, let it to be under the URI “/special-page”. So, enter that URI in the textarea without quotes. The matching criteria is “if the current URI starts with one of the specified, just skip the caching system”. Read the criteria, you can use the partial URI “/special” and the special page will be still rejected.”