[Plugin: Login Security Solution] password must be at least 7 characters

Yeah, this is a pain. Sadly, WordPress has their password policy text hard coded in four different places. Plus, that means there’s no filter for overriding it. Very silly. Opening a WP core ticket for this problem is on my to do list.

The only thing I can do at this moment is make my error message specify the needed length and say something like “Ignore what WordPress says.”

As a word around consider adding a filter to gettext, capturing the specific text as it comes through and changing it.

The text in all 4 places is the same in the lastest version of WordPress:

Hint: The password should be at least seven characters long. To make it stronger, use upper and lower case letters, numbers and symbols like ! ” ? $ % ^ & ).

Dean:

That seems like it would add significant overhead. Such a filter would be executed each time gettext is called, which is a LOT.

–Dan

Dan,

If you couple adding the gettext filter with the specific display of those pages where the message is displayed the overhead is minimal.

Adding the gettext filter on these actions should be sufficient:
* action: login_init
* filter: show_password_fields

The specific case inside install.php need not be handled because this only occurs at the initial setup of the blog.

–Dean

Dean:

Food for thought. Thanks for the researching that, Want to make a patch against a Subversion checkout?

And thanks for paying attention to this plugin’s support threads.

–Dan

This request has been implemented in the 0.20.0 release. Everyone, thanks for the report and suggestions.

Could y’all please be so kind as to rate the plugin, vote for it as “working”, and (ahem) make a donation?

Daniel, just so you know, I’m not actually using the plugin on any production site because of the “philosophical issue” over delay versus block, which means I’m sticking with Limit Login Attempts.

I’ve been testing yours on a dev site not accessible to the public, mostly for my own education, to see how it plays with other plugins and so on, and if I notice anything I flag it. To avoid misunderstanding I’ll remove it sometime this week when I go back to the dev box.

gwc_wd: Thanks for letting me know. What’s the philosophical issue? FYI, LLA has a hole because it misses auth cookies with an invalid user. –Dan

The issue is that I need the ability to block and not be forced to accept escalating slow downs and you’ve made it crystal that you will not incorporate this as an option. Ergo I need a different solution.

Hi gwc_cd:

Another perspecitve on the “slow downs vs blocks” debate came to me the other day. It turns out Login Security Solution does indeed block. (Where “block” means “denies access” to attackers.) Below is a comparison of the attack handling logic used by Limit Login Attempts and Login Security Solution.

Limit Login Attempts

Invalid or Valid Credentials by Attacker or Actual User

1. Process authentication request (check IP address)
2. Error message: “Too many failed login attempts.” (ACCESS DENIED.)

Note, this approach means an actual user can be denied access for 12 hours after making 4 mistakes.

Login Security Solution

Invalid Credentials by Attacker or Actual User

1. Process authentication request (check IP, user name, and password)
2. Slow down the response
3. Error message: “Incorrect username or password.” (ACCESS DENIED.)

Valid Credentials by Attacker

1. Process authentication request (check IP, user name, and password)
2. Slow down the response
3. Set force password change flag for user
4. Error message: “Your password must be reset. Please submit this form to reset it.” (ACCESS DENIED.)

Valid Credentials by Actual User

1. Process authentication request (check IP, user name, and password)
2. (If user is coming from their verified IP address, let them in, END)
3. Slow down the response
4. Error message: “Your password must be reset. Please submit this form to reset it.” (ACCESS DENIED.)
5. On subsequent request… user verifies their identity via password reset process
6. User’s IP address is added to their verified IP list for future reference

So both plugins deny access to attackers. But Login Security Solution has the bonuses of letting legitimate users log in and slowing the attacks down. Plus LSS monitors user names, passwords, and IP’s for attacks, while all of the other plugins just watch the IP address.

I’m curious what your thoughts on this perspective are.

I think different admins have different experiences and so different needs, and that Login Security Solutions nicely meets the needs of a significant set of admins.

My experience is that I have never had a user that required 3 times to get their login credentials right, so I have much less concern about blocking legitimate users than some others who have a different experience.

My experience is also that the overwhelming proportion of “bad” login attempts are attacks conducted by bot hosts, many of them bizarrely stable (bizarre because I would have thought that attackers would be shut down quickly by their ISPs, but no, they can live on the same IP even when they are known bot hosts, esp. Russia, China and Korea).

Most importantly, the attacks almost invariably are sourced from servers, not from consumer IP addresses. Since my web sites offer nothing that should invite another server to make a connect, I have no concern about them being unable to successfully connect to my sites. I do not want to block a server for some number of hours, I want it blocked forever.

The concern about innocent victims who have been infected or hijacked just doesn’t enter into it, because the infected source is almost always a infected web site, not an infected personal computer.

So “block” in the sense I have been using it is not to block the user but to block the IP permanently and this is the central difference between the LSS approach and some others.

LLA effecively allows a permanent IP block by setting the time to 9999 hours (2.3 years), such that the blocked IP never gets to the login screen at all. So a blocked IP does not get a chance to the “Check Authentication process.” <–Am I wrong about this?

Now, all of that said, I have had the best possible solution brought to my attention by a user “So_about_that” from Spam Security Forums:

ZBBlock

Using its custom signature rules, I do an “instaban” (immediate permanent IP block) on specific user name attempts, notably “admin” which has not only taken care of 100% of the login attacks against my sites, but has reduced the number of attempts from several dozen per day to a handful per week. It *appears* that bot writers are detecting ZBBlock and removing the hosting site from their targeting algorithms.

ZBBlock is much more capable than just dealing with login attempts and has an active malicious IP detection and blocking system. It has also allowed me to create a rule that eliminates login username enumeration that is hard coded into WordPress.

I still use LLA for potential login attacks that do not use one of the forbidden user names. But since installing ZB, LLA has not been exercised on a single occasion. It has also allowed me to be more charitable toward clumsy or forgetful users by raising the failed attempt to the 4 tries so often cited, since I have confidence that ZB is taking care of the great majority of actual attacks.

I also use http BL, Akismet, some special htaccess rules and run a ProjectHoney trap. None of which have had anything to do since installing ZB. So ,I strongly recommend ZBBlock to all WordPress admins. It’s free, it has great user forums and is blessed with a developer who shares one characteristic you clearly have: active and interested in his code and the users of his code.

The only thing missing is for a WP plugin developer to write a plugin to automate the ZB install and update it when WP core is updated. (ZB is not WP-specific, working on all web apps that use php, so the author who does not use WP himself has no reason to write such a plugin himself).

For the record, if I was starting over and didn’t have ZB, I’ve been persuaded that LLS is a better option than LLA, almost entirely from following the two support forums. Even given the trade offs I mention above, it seems to me that the most critical factor is that Limit Login Solutions is simply better code. When dealing with security hardening, that counts a Lot.

Hey gwc_wd:

Wow! Thanks for the thoughtful response.

I would have thought that attackers would be shut down quickly by their ISPs

Yeah, tell me about it. ??

LLA effecively allows a permanent IP block by setting the time to 9999 hours (2.3 years)

You can jack up the “Match Time” setting in LSS to obtain the same effect.

The blocked IP never gets to the login screen at all. So a blocked IP does not get a chance to the “Check Authentication process.” <–Am I wrong about this?

Attackers use scripts that directly submit POST requests, so WordPress’ authentication actions are called even if the form is hidden.

ZBBlock

Interesting. I downloaded it and will take a look.

Thanks again,

–Dan

The FAQ has been updated with a section entitled “Will you provide lock outs / blocks in addition to slow downs?” based on the “perspective” post, above.

Daniel,

What is a good Comment Character Limiter plugin to use? I have LSS & akismet installed and wanted something compatible with that or do I even need a CCL?

One of my sites recently was infected with malware. I’m trying to do as much as I can to prevent it(I know nothing is 100%) just trying to make it as secure as possible.

Thanks