In this article I'll show you how to lock down and password protect your WordPress website from invalid login attempts. We'll do this by limiting access to the /wp-admin directory and the wp-login.php script.

If you haven't already, please read my article about WordPress wp-login.php brute force attack. These attacks are what helped prompt me to write this article.

Password protect WordPress logins

Using the steps below, I'll show you how to create password protection for your /wp-admin directory. We'll also copy those rules over to protect your wp-login.php script.

Please note that users have reported to us in certain cases following these steps will result in a re-direct loop. If you're having that issue, please ensure you have the following two entries at the top of both .htaccess files:

ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

You may get password prompts even when you aren't trying to login to WordPress. Usually this is because of plugins. Please make sure to allow /wp-admin/admin-ajax.php requests without password protection.

 

  1. click on password protect directories

    Under the Security section, click on Password Protect Directories.

  2. select document root click goSelect the Document Root for your domain, then click Go.
  3. click on wp adminClick on your wp-admin directory.
  4. check password protect name directory click save

    Check Password protect this directory, give it a name, then click Save.

  5. click go backNow click on Go Back.
  6. click on password generator and use passwordClick on Password Generator.
    Click on Generate Password a few times, and copy your password.
    Check I have copied this password in a safe place.
    Then click Use Password.
  7. click on add authorized userNow type in a Username, then click on Add/modify authorized user.
  8. authentication required click on log inTry to access your /wp-admin directory.
    Your browser will prompt you for the username/password you just created.
    Type them in, and click Log In
  9. wordpress admin click on log inYour normal WordPress admin login page should now display.
  10. You might encounter a re-direct loop at this point. If so, please ensure you've created the error documents mentioned earlier in this article.

  11. click on file manager and goNow go back to cPanel.
    Under the Files section, click on File Manager.
    Select the Document Root for your domain.
    Check Show Hidden Files (dotfiles), then click Go.
  12. click on wp admin and edit htaccess fileFrom the left-hand directory listing, expand public_html.
    Click on wp-admin, then right-click on your .htaccess file.
    Then click on Edit
    For the encoding pop-up, click on Edit again to bypass that.
  13. copy htaccess text

    Copy all the code in the .htaccess file.

    While you still have the /wp-admin/.htaccess file open, also go ahead and add the code in red:

    ErrorDocument 401 "Denied"
    ErrorDocument 403 "Denied"

    # Allow plugin access to admin-ajax.php around password protection
    <Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any
    </Files>

    AuthType Basic
    AuthName "Secure Area"
    AuthUserFile "/home/example/.htpasswds/public_html/wp-admin/passwd"
    require valid-user

  14. click on public_html and edit htaccess fileFrom the left-hand directory listing, click on public_html.
    Right-click on your .htaccess file, then click on Edit.
  15. save public_html htaccess file

    Now paste the .htaccess code you copied, in-between some <FilesMatch> tags, so that it ends up looking like this:

    ErrorDocument 401 "Denied"
    ErrorDocument 403 "Denied"

    <FilesMatch "wp-login.php">
    AuthType Basic
    AuthName "Secure Area"
    AuthUserFile "/home/example/.htpasswds/public_html/wp-admin/passwd"
    require valid-user
    </FilesMatch>

    Then click on Save Changes up at the top-right.

  16. wp login bad password attempt

    Now if someone tries to directly login via wp-login.php they will be prompted for a valid user as well.

  17. wp login bad password attempt blocked

    When a user enters invalid credentials are, they will get an Authorization Required error. They will then not be able to attempt to login to your WordPress admin directly.

You should now know how to requre a username and password before an attempt to directly login to WordPress is even allowed. This will help to protect your WordPress website from unauthroized login attempts.

Did you find this article helpful?

We value your feedback!

Why was this article not helpful? (Check all that apply)
The article is too difficult or too technical to follow.
There is a step or detail missing from the instructions.
The information is incorrect or out-of-date.
It does not resolve the question/problem I have.
How did you find this article?
Please tell us how we can improve our Support Center:
Email Address
Optional, but our team may contact you for more information.
Like this Article?

Comments

Post a comment
Staff
5,534 Points
2013-04-12 7:11 pm
Hey jkwalz, and thanks for the great comment.

I fixed your problem for you, and updated this article to also reflect the need to define ErrorDocument in certain cases like yours.

Let me know if you're still noticing any issues at all.

- Jacob
2013-04-13 3:39 am
A very unsatisfactory solution!

My WordPress site has an subscriber only are, these 600 plus subscribers (growing daily) all want to log in using wp-login.php, so I must now submit our website subscribers to this extra authentication - just tell me how!!!

Absolutely impossible - a solution that inmotionhosting must rethink

I remind the inmotionhosting system administrators that WordPress allows four user catagories 1) subscribers 2) contributors 3) editors and 4) administrators all of these logging in through wp-login.php
With this ill thought fix inmotionhosting is disabling a WordPress feature of allowing member only area on a WordPress designed website.
2013-04-13 5:06 am
Furthermore, I have just run a test; wp-login.php gets blocked by a primitive counting method being applied on the rate of access and not by the rate of failed logins as previously stated in the article http://www.inmotionhosting.com/support/news/general/wp-login-brute-force-attack (see comment posted 2013-04-12 2:44 pm).

The test is as follows - I have opened successive browser tabs and opened the login page and have not entered a single character into any field, on opening the 6th browser tab with wp-login.php the site gets locked out.

In continuation of my above post, that means if our users want to login or even new users want to register, and this happens by chance in a short time the site or rather wp-login.php gets locked out .

I am now delaying a promotion campaign to attract new users to the site as a random lockout can occur. As the intention is to monetise the site any lost registered user is lost future income.

I urge the system administrators to rethink what they have done. Being wrong footed is no excuse foi bad solutions - brute force attacks on WordPress sites have been around for some time, they only increased in three fold in the past days, seemingly the earlier attacks were ignored see http://blog.sucuri.net/2013/04/mass-wordpress-brute-force-attacks-myth-or-reality.html
Staff
5,534 Points
2013-04-13 5:27 am
Hello Anton_Vrba, and thanks for your comments.

The method explained in this particular article as you've mentioned isn't ideal for WordPress websites dealing with multiple users. The blocking of the WordPress wp-login.php script you're right, doesn't necessarily need to be failed login attempts.

As mentioned in the other article you pointed out, we recommend users first try to block WordPress brute force attempts by referer, as this doesn't have the limitations of only allowing access to select IP addresses.

The code would look like this:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^http://(.*)?example\.com [NC]
RewriteCond %{REQUEST_URI} ^/wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/wp-admin$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>


Previously WordPress brute force attacks were able to be handled on a per-site basis, typically with a WordPress security plugin, or some .htaccess rules. But this recent tripling of the current botnet's attempts made more extreme measures necessary. From what we've been seeing, it's pretty common that most web hosts are employing very similar server-level blocking tactics, and some have still yet been able to provide their customers with a viable solution for regaining access to their WordPress admin dashboard.

Again I can't stress enough that these recent security updates were required in order to ensure that servers weren't crashing from the huge flood of malicious requests. I apologize for any temporary inconvenience that these issues have caused for you.

- Jacob
2013-04-13 7:24 am
I have tried implementing the .htaccess fix as JacobIMH recommends above (testing if referred), after six referred wp-login.php attempts, that is clicking on the login link on the home page - I still get locked out by a primitive and simple counting solution of wp-login.php accesses that does not take failed login attempts into account
2013-04-13 8:31 am
Hi Jacob,

I have followed these instructions on alvinbaseball.org yesterday, but the additional login is not displaying. I must still be under attack because I am still getting the blocking message that links to your brute force article.

Thanks,
Karen
2013-04-13 11:15 am
Quote: "The method explained in this particular article as you've mentioned isn't ideal for WordPress websites dealing with multiple users. The blocking of the WordPress wp-login.php script you're right, doesn't necessarily need to be failed login attempts."

This is not business friendly! If you cannot find a solution, I kindly request you to migrate the multi-user WP websites to a server that has not got this amateur solution implemented, however you need to enforce industry accepted Captcha rules on the login pages - that way no bot is going to acces the site. The website imarketsigfnals.com has such a Captcha implemented.
Staff
5,534 Points
2013-04-13 12:33 pm
Hello again Anton_Vrba,

Please understand that only WordPress login access is denied for 15 minutes, the front-end of a WordPress site would still be running as normal. These were also emergency security protocols put in place to ensure that the security risk didn't escalate, and to protect our user base.

If you've placed the .htaccess rules in place, do not attempt 5 requests to wp-login.php within 30 seconds, or another 15 minute block could be put in place. You can also simply temporarily disable mod_security via cPanel for a shared hosting account, or if you have root access to a VPS you can disable mod_security for a domain. Then I'd recommend re-enabling it to protect yourself from other security risks, but it should reset the counter and allow you access to login again.

So it's not necessary to migrate multi-user WordPress users to another server, as they can disable the blocking we've implemented after protecting themselves via .htaccess. Unfortunately a CAPTCHA solution typically requires far greater processing power as they are handled by scripting languages like PHP, instead of much more efficient solutions like mod_security or .htaccess rules on the server level.

With the scale of this attack, it's simply not feasible to challenge every malicious request on the server, you might be interested in checking out a DNS level filtering solution. Due to the huge impact of this attack on the Internet, CloudFlare has offered DNS protection against this attack on their free plan.

This is a global issue affecting multiple hosting providers, and based off some Google searches, InMotion Hosting is actually one of the trending authorities on the approach of handling this problem. An example of this can be found at Slashdot.

We apologize for any negative impact on your business, as you can imagine with our business being running servers to provide customers a platform to connect to the world with, we were being extremely negatively impacted like the rest of the web hosting industry as well.

We saw a huge influx of malicious brute force login attempts, coming from this reported to be as high as 90,000 server botnet, and quite frankly above all we wanted our customer's data and security protected. The percentage of users that need to login to WordPress or their business would be hurt, is magnitudes lower than those businesses that could not afford a successful brute force login, which could then lead to script injections, hosting malicious content, a negative domain reputation with Google, and not to mention any information stored in their database being collected by these malicious attackers.

Hopefully this attack will cease shortly, and full unfiltered access can be restored to all customer accounts. In the meantime we will continue to look for other solutions that impact fewer and fewer customers while ensuring that our total customer base is protected from this attack.

- Jacob
Staff
5,534 Points
2013-04-13 12:48 pm
Hi again Karen, sorry for the ongoing issues you've been having.

I went ahead and resolved this for you. I went ahead and implemented some .htaccess rules for you to limit access to /wp-admin and wp-login.php by referer.

It looks like the block was still happening, I believe due to the login plugin you have. Since you have a VPS I also went ahead and disabled the specific mod_security rule for that website.

Please let us know if you continue to experience issues.

- Jacob
2013-04-13 1:05 pm
Hi Jacob,

I appreciate your attention to the matter; however, I'm still experiencing the same behavior from that website.

Thanks,
Karen
2013-04-13 2:01 pm
Jacob,

I just looked at the .htaccess file in that website, and I do not see the changes specified in "limit access to /wp-admin and wp-login.php by referer."

I have a few websites that I need to "jailbreak" from this lock pretty soon, particularly this one that needs an urgent message posted and another one for which I have a meeting scheduled with the client next week to go over updates.

I really had hoped to get a lot of other things done this weekend, including going live with a new (non-WordPress) site. I realize that you guys are doing the best you can, and I sincerely appreciate your efforts on my behalf, but this situation is starting to cost me money. Is there any other possible way to protect the sites from bots while still allowing access to legitimate (and multiple) users?

Also, I'm curious why password-protecting wp-admin did not produce the additional login window for this site. Perhaps the DNS has not yet propagated on my new server. I performed the action from cPanel using the provided temporary URL. When I try to use the permanent URL to reach cPanel, I still get the old cPanel that I had on the old server.

Thanks for your help,
Karen
2013-04-13 2:19 pm
Jacob,

Is inmotion aware of this patch from Cloudflare?

http://blog.cloudflare.com/patching-the-internet-fixing-the-wordpress-br

Thanks,
Karen
Staff
5,534 Points
2013-04-13 6:16 pm
Hello again Karen, sorry that the problems kept up for you.

When I hopped onto your VPS I discovered that the Apache configuration had been updated to not include the exception I had included to stop the mod_security rule we deployed from triggering on your domain had reverted. I know it was working before I replied to you as I was testing it out, so I apologize for that.

The website should be allowing you to login again normally now. We are aware of CloudFlare offering DNS filtering against this attack with their free level of service. I mentioned this a few comments up offering CloudFlare DNS protection as another viable solution to these recent attack issues.

Unfortunately employing a DNS filtering solution is much slower, as you have to update each of your domain name's name servers to point to CloudFlare. You then also have to typically wait 24-36 hours for all DNS records to fully propagate.

I've actually been doing some testing with CloudFlare, and if there is enough interest I can definitely do another detailed article on how to configure their DNS filtering for a domain. For the time being however, I would simply recommend going directly to their blog post we've both linked to, as they've got a pretty streamlined process that walks you through setting it up.

Sorry again that the problem came back after I told you it was resolved, I'm leaving a session open to your VPS and monitoring for further issues. But if you did notice some yourself that I didn't catch please let us know.

- Jacob
2013-04-14 1:28 am
Hello again Jacob
I do understand your actions but first you please understand that all my users want to log in to read todays news. You also do not read last months newspaper, and my sites front end is the last months newspaper

Secondly, please send the system administrators my kind regards and inform them how super naive and primitive I think their counting solution is. The hackers, once aware, will round robin their attack over many sites to keep the rate of attack on each individuel website below the trigger rate they have set. As Karen points out, there is only one effective way and that is to terminate any data or request belonging to a malicious source IP i.e. the CloudFlare solution.
2013-04-15 7:26 am
Hi Jacob,

Kind of a late reply, but I forgot to click Submit...

I actually signed up for the Cloudflare solution before you answered above so that I could see what it was about, and I think it would be great if you have one or two sites. However, it would be tedious at best for those of us with 20+ sites to rollover. I don't have that kind of time, and since I just moved to a new server, I don't want to go through DNS propagation again anytime soon! I'm going to try your solution first as I see the logic of the it. If the bot can't get to the login page due to .htaccess rules, it's done. We just have to make sure that we have the rules correct.

Isn't there also a rule that denies access to .htaccess? I'll have to look that up. ADDENDUM: After I initially wrote this message, the .htaccess seems like a great solution for the one site for which I have it set up. I want to extend this solution to my remaining WP sites ASAP.

I would like to add one more thing. Although it was HIGHLY inconvenient and alarming to be locked out of our WordPress sites, I want to commend inmotion for its decisive action against the global attack. The first and foremost goal had to be to protect our data and the data of countless others, and that was done. To my knowledge, none of the inmotion servers were compromised. I know my server wasn't. I and my clients would rather have a couple of days of stagnant content than have our sites down or contribute to and be victims of what could have been the worst hacking attack in world history. That scenario would have been MUCH more inconvenient. Hats off to you, and many thanks for your professionalism during this crisis.

Thanks,
Karen
2013-04-15 8:39 am
Karen, Your praise to inmotionhosting is rather nice but consider following:

According to http://blog.sucuri.net/2013/04/mass-wordpress-brute-force-attacks-myth-or-reality.html these attacks have been prevalent for the last couple of months, in December 2012 about 15K attacks a day, In January 2013 40K per day and now 80K. The hosting companies did nothing for 4 months to do something about it, until panic broke out. The reason why the hosting companies are panicking is that the hackers are installing plugins with which they can take control of the servers, the servers as malicious bots can and will cause great danger if unleashed - that is the real problem, that they looking after you is good PR, they did not care for the last 4 months. How many password the hackers have to get in WP sites is unknown, but I read they had a 10% success rate.

Secondly, my site and I hope your too, are using obscure user names for administration level login with 15+ characters in the password. Furthermore all the logins from all users has a second tier authentication by a Captcha. Any one who has less is asking for trouble!
2013-04-15 8:48 am
PS: Even logging in to make a comment on this page is very risky. You are logging in with your AMP credentials and it is not a secure link - no https
2013-04-15 10:57 am
Does this work with Wordpress multi sites?
(as the login is on a re-direct)
2013-04-15 2:36 pm
Jacob,
Thanks for posting info and taking questions. Our site BookTrib.com has thousands of members. Today, for the very first time while this craziness is going on, I got an email from a member - who doesn't have dashboard but was blocked and got the cyber attack message. [InMotion's message is about not being able to login to a dashboard, not login to a website. Improving the message would be great by the way.]

My big concern when I saw that message is that we have major authors chat with our members via streaming video - so I could have 100+ people coming to watch and chat. I am totally freaked out about people not being able to get onto the site. I thought this was a issue for logging into dashboard - not the site. Thoughts?
Staff
5,534 Points
2013-04-15 8:12 pm
Hey Karen,

Sorry for the delayed response, been writing security articles all day.

Yeah CloudFlare seems like a great solution if you just have a few sites, so hopefully all the .htaccess rules work out for all your websites.

You can prevent access to a specific file in .htaccess, to deny access to the .htaccess file itself you'd use:


<Files .htaccess>
order allow,deny
deny from all
</Files>



I definitely appreciate your kind words, we were trying to prevent the worse case scenario and it looks like that's been accomplished at this point.

I've also gone ahead and extensively updated our WordPress wp-login.php brute force attack article to include "10 recommended steps to lock down and secure WordPress" which should cover just about all the bases you'd want to take as a WordPress user to make sure your websites are safe.

Please let us know if you continue to have any issues or any further questions.

- Jacob
Staff
5,534 Points
2013-04-15 8:18 pm
Hello again Anton_Vrba,

Just like every other hosting company out there, we had seen WordPress as well as other CMS brute force attacks in the past. However this recent attack was triple anything previously encountered, and at that scale and scope of attack, the previous unintrusive security policies we had in place worked perfectly fine to protect our customers.

It's not that we did nothing during these previous attacks, we were simply able to mitigate them without impacting our user's ability to login to their sites. The sheer volume of failed login attempts this time around had not been seen before, and that's why more extensive security rules had to be employed.

-Jacob
Staff
5,534 Points
2013-04-15 8:20 pm
Hello FROnline,

I believe our .htaccess rules should also allow for WordPress multisite. If you were having any issues at all still logging into a particular site please let us know!

- Jacob
Staff
5,534 Points
2013-04-15 8:24 pm
Hey DavidMoore,

No worries at all, I'm just glad you were able to get things all straightened out. If you have any recommendations on how I can make the instructions any clearer so other users don't possibly miss any steps either, I'm all ears.

- Jacob
Staff
5,534 Points
2013-04-15 9:16 pm
Hello hulamonkey,

No problem at all, that's what we're here for.

Unfortunately we have seen some cases where WordPress websites that have a lot of users, just doing normal activity such as commenting, can in some rare certain cases still trigger our security rules, and still result in a block. I'll see about having our system admin team update the verbiage in the warning as well.

I took a look on your server using the tactics described in my article on how to find and disable specific mod_security rules, and it did appear your site was triggering our security rule.

Because it sounds like your site needs to have lots of hits to the wp-login.php just for general activity on your website, I've gone ahead and disabled our mod_security rule on just that one website for you, after I made sure to lock down WordPress admin login by referer.

This should prevent further issues for you. If you're still seeing any problems at all, please let us know.

- Jacob
2013-04-16 3:12 am
Hi Jacob, Your reply to the comment of hulamonkey is music to my ears, I have tried all day Friday and Saturday to have an elegant solution like that for my site http://imarketsignals.com (primary domain absolutivity.org), but to no avail (I have about 8 chat transcripts explaining exactly that but no result).

My site imarketsignals.com as hulamonkey's site needs lots of hits to wp-login.php for general activity. Thus, please be so kind and implement the same mod_security exception for imarketsignals.com, then I can undo my primitive circumvention of your rule by sending everyone to my-login.php, a solution that left a few links on the site still pointing to wp-login.php, but I stayed alive for my large amount of subscribers.
2013-04-16 7:44 pm
Hey Jacob,

You seem to be the man who is actually getting things fixed for some people. I am now resorting to posting here to see if you might be able to work your magic for wordpress installs that I and my clients have been unable to access since Friday. I have worked with a number of techs over the last few days. Mike (who was able to get it to work for about an hour yesterday morning when they all broke again), then a Josh yesterday afternoon (which Josh I am not sure as I guess there are a couple -- he was very kind since my frustration level has escalated through each tech person I get who tells me if that doesn't fix it calls us back as we are here 24/7).

Josh at the end of our conversation last night when he couldn't also figured out why the fixes he had done didn't work assured me my ticket #1382839 (created by Ervin on Saturday morning) was still in the system, but since I am now going on the 5th day of not being able to access wordpress sites for updates I am getting a bit desperate for help. I even emailed this morning on my ticket to see what the status was, no response.

Both I and IMH techs have tried all the suggested methods for the htaccess files to no avail. Both domains that I am having issues with (hoping you can pull those from the ticket) are on VPS servers, so that is extra frustrating as my clients expect a bit more than what you get from shared hosting (which by the way the htaccess fix worked just fine for my own account on shared hosting -- the cheap hosting was actually a benefit this time <G>).

I have truly been an IMH fan for a number of years and both of these clients moved to IMH on my recommendation, so I am hating to tell them day after day that things are not fixed and I have no update of even the status. (Besides the email yesterday morning on my ticket that said things were fixed, when they weren't.)

Thanks for any additional help/insight you might be able to provide.
2013-04-16 7:46 pm
P.S. I did just try implementing the CloudFlare on theteacherspath.com domain, but awaiting dns changes to see if that helps. Just thought I should throw that out there.
Staff
2013-04-16 8:52 pm
Hello Dbuxton,

We do apologize for the issues. I did review the issue, and the ticket you provide (#1382839) has been replied to by our Systems team. It states that the attack has stopped and you should be able to access it now. I was able to pull the admin login on at least one of the sites there in testing. Please also make sure to review the following article for more information:

Lock-down WordPress Administrator login page

They are recommending that the Single IP and Multiple IP solutions are currently the best way to limit access to the login page for WordPress.

If you have any further questions, please contact technical support available 24 hours a day / 7 days a week.

Regards,

Arnel C.
Community Support
Staff
5,534 Points
2013-04-18 6:54 pm
Hello again Anton_Vrba, sorry for the delayed response,

It looks like your issue was that you were experiencing the .htaccess referer error when that article was first published into its own separate article. When the HTML content was copied from it's original source, our publishing platform stipped a space in-between where your domain name would go and the [NC] flag, and this was causing the 403 blocking to not work, which in turn caused the mod_security rules to trigger.

If you keep having issues with the block, because you're on a shared server. I would recommend that you temporarily disable mod_security via cPanel Modsec Manager. Once you're logged into your WordPress site successfully, be sure to go in and turn mod_security back on, that way you're still protected from other types of malicious attacks.

Please let us know if you continue to have issues.

- Jacob
2013-04-30 10:12 am
Hi Guys, I have tried the above mentioned (password protect admin directory and adding stuff to .htaccess for wp-login.php and I do get the popup for username and password to access wp-login. I type the username and password and then I see the glorious wp-login page. Thought I had solved the issue. As soon as I type my username and password and hit login, BAM that block slaps me right in the face. It has been more than 5 hours when I password protected the directory and added code to the .htaccess file. This thing is just going round and round and round. Can I please now login to my blog without watching that BLOCK page? I have waited weeks and it is hard for me to wait any longer, I can't risk my rankings for not posting content on my websites. PLEASE find a solution to this problem. Please help me here I'm losing on my business. Thanks for your help Mods.
2013-04-30 10:16 am
My website is toptenantivirus.net and there are about 6 different blogs hosted on my VPS account. All of them have the same problem. Mods please give me a clue what more I can do to stop that BLOCK script from showing up. I have password protected the admin directory and the wp-login.php on my blogs so there shouldn't be an issue, right?
2013-04-30 10:25 am
Andy -- after 2 weeks of getting no where with IMH we finally had to move to new hosting service. Tried forever to work with admins as had VPS. The last straw was last week when we were finally able to get into our WP panels (we had to designate our IPs), when we found out none of our customers could get into password protected areas of our sites that they paid for. On top of that IMH kept telling us they "could not replicate" when I could (simply using an IP not assigned in our htaccess file) and a dozen or so of our customers.

It is really sad that IMH has not fixed this for you and others. I now have 2 other clients moving off IMH (even 1 with a VPS) and I will be moving my accounts in the next few months also. I often had great support with IMH, but with this issue I definitely felt talked down to and dismissed on more than one occasion from techs -- not a great feeling when you been at this for nearly 15 years.

I wish you the best, but not sure you can count on a resolution at this point especially after nearly a month.
Staff
10,075 Points
2013-04-30 11:41 am
Hello andyks,

Since you have implemented the other protective measures, we can disable the mod_security rule that is causing the block. To do so, you would need to contact our Live Support department at support@inmotionhosting.com with that request. Be sure to validate your account with either the last 4 digits of the credit card on file, or the current Account Management Panel (AMP) password.

Best Regards,
Scott M
Staff
10,075 Points
2013-04-30 11:46 am
Hello d_buxton,

As I said with andyks above, the rule can certainly be removed if requested. As we are working toward a much more customer-friendly solution, we would hate to see anyone leave due to the current issue.

I also apologize if you felt any technician was belittling in their comments to you, that is not how it should be. Feel free to contact our management on that issue. We want to provide friendly support regardless of the situation.

Please let us know if you would like to have the rule removed from your sites.

Best Regards,
Scott M
Staff
5,534 Points
2013-04-30 1:39 pm
Hello andyks, sorry for the problems.

I went ahead and responded to your other comment with what I've done to allow you access to your WordPress websites again.

Please let us know if you're still having any issues at all.

- Jacob
Staff
5,534 Points
2013-04-30 2:07 pm
Hello d_buxton, really sorry for the troubles you had with your account.

Based off of the email account this comment was submitted under, I'm only seeing one support ticket from 2 weeks ago, and it doesn't appear there were any chat or phone calls logged for the account.

In the support ticket, I do see where we had attempted to replicate the issues you were having, and at that time were unable to get the mod_security rules to trigger a block of the WordPress admin section at that time.

Unfortunately it looks like the only indication we had that things were not working for you still was you commenting on this article on 4/16, and then we responded on 4/17 letting you know we had responded to your support ticket. We didn't hear anything past that, so I apologize if you continued to have problems accessing your sites.

Taking a look at the server's mod_security logs, I'm still not seeing indications of your WordPress access being blocked by our rules. So it could be possible that you're having a unique issue that we haven't seen happen yet for any customers.

If you're possibly talking about another account that this email address isn't associated with, then I could possibly be overlooking something. I would recommend contacting us via live chat to try to have any further issues ironed out.

- Jacob
2013-05-22 9:09 pm
I appreciate the work on this - but my question is - is there any reason this would not work with a temp url? It seems to challenge on the public side of the site, when i put it in place, but not on the login access page?
Jim
Staff
5,534 Points
2013-05-22 9:49 pm
Hello Jim, and thanks for your comment.

More than likely the .htaccess ErrorDocuments are not in your .htaccess file.

As the directory password protection should work regardless of you using the temporary URL, or the main one. However when loading over the temporary URL, ErrorDocument pages are pulled from a different source than accessing the domain directly.

Please let us know if that did the trick for you!

- Jacob
2013-06-07 5:05 am
Hi. I've password protect my WP admin using cpanel. I've also have another webpage that is passwd protected (set up from WP) after I insert the 1st password get a request for the wp-admin password that I set up from cpanel
The issue is to put sipmly: accessing wp-admin requires now two passwords and that's fine. however as soon as I password protect any of my WP webpages it requires two passwords: the one set from WP (fair) and the other for wp-admin that I set up from cpanel. So if I want to direct someone that that page I'd need to give them two passwords!
try this as a test please: http://downloads.kankanmedia.org/test/ password: test
Staff
5,534 Points
2013-06-07 2:40 pm
Hello ooartur, and thanks for your comment.

Unfortunately with the way that .htaccess password protection is configured, when you're matching any requests to the wp-login.php script it will require a valid username and password.

It looks like with the way that you're password protecting your pages within WordPress, it's requiring them to also run through the wp-login.php script, and this is why you're getting prompted for two sets of credentials.

I've tried to play around some with various .htaccess options such as trying with SetEnv and SetEnvIf rules to attempt to capture the requests for the separate one-off wp-login.php requests and store them in a variable, to later allow them to bypass the password prompt. However after some more research it looks like these rules are not processed prior to the authentication ones and so don't work in this case.

I unfortunately have yet to find a viable solution for this scenario in which it can be completely automated. One possible work around, would be to allow your members that will be downloading files by their IP address. But of course this would require you setting that up prior to them attempting to access the files to avoid the double-password prompt.

Here is an example showing how I allowed our office IP address to bypass the secondary .htaccess password prompt:

SetEnvIf Remote_Addr "174\.77\.92\.170" members
<FilesMatch "wp-login.php">
AuthType Basic
AuthName "wpadmin"
AuthUserFile "/home/userna5/.htpasswds/public_html/wp-admin/passwd"
require valid-user
Order allow,deny
Allow from env=members
Satisfy any
</FilesMatch>


If you wanted to allow any other IP addresses to bypass the password protection, you could just keep adding lines under the SetEnvIf Remote_Addr line adding them to the members variable so that they are allowed access.

I'll try to keep an eye out to see if there are possibly any other ways to automate this type of access for you.

- Jacob
2013-06-09 11:26 am
Thanks for looking into it Jacob. For now my workaround is to remove the password-protection from the those pages and instead password-protect some information from them by putting it in a file (.pdf for example) and password-protecting its download, with a WP plugin. I mention it here just in case someone else has a similar problem.
Staff
5,534 Points
2013-06-10 10:49 am
Hello again ooartur,

No problem at all. Yeah unfortunately it looks like if you're setting up a credential system within WordPress itself, and it relies on using wp-login.php it's going to have a double authentication prompt when using our .htaccess rules to require a password. The workaround that you mentioned is a great way to resolve this type of access problem, but I'll keep looking to see if there is a more permanent solution.

- Jacob
2013-06-26 3:39 pm
When I use the following .htaccess file on the subdomain(test.mydomain.com), I get the error "310 (net::ERR_TOO_MANY_REDIRECTS)" and can't access the log-in page.

<files wp-login.php>
AuthName "Login"
AuthType Basic
AuthUserFile /home/xxxx/.htpasswd
require valid-user
</files>

Although I have tested on the local using XAMPP creating subdomain “test.localhost” and subdirectory on the inmotion server "mydomain.com/test/ " with same files and it works fine.

Why am I getting the error only on subdomain settings?
Staff
5,534 Points
2013-06-26 4:13 pm
Hello tkobay5, and thanks for your question.

It looks like you just needed to follow the instructions from this article regarding the redirect loop that several users have encountered.

I've gone ahead and implemented this for you, and it looks to have stopped the redirect loop problem you were having.

Please let us know if you're still having any issues at all.

- Jacob
2013-06-26 4:22 pm
Hi Jacob,
I'm sorry that I didn't read carefully.
And thank you so much for your help now it's working.
2013-07-13 2:04 am
Hello Jacob

I successfully followed your instructions and password protected my wordpress logins. Now I have I problem with my site visitors. Everytime someone wants to read an article a screen comes up asking them for a username and password. How can I stop that screen from popping up while still password protecting my site?
2013-07-15 8:28 am
I have done what the article says but Step 16:'When invalid credentials are entered in, the user will get an Authorization Required error, and not even be able to attempt to login to your WordPress admin directly.' doesn't work. After invalid login the box popups again and the error is not shown
Staff
5,534 Points
2013-07-15 1:06 pm
Hello MarwaRakha, and thanks for your question.

It looks like all of your posts are trying to include the /wp-admin/admin-ajax.php script, seemingly from the WP-PostViews plugin that you have installed.

Because it's trying to pull a file from the /wp-admin directory that you have password protected, this is why people just trying to read an article would be getting the prompt as well.

I went ahead and added some further code to your .htaccess file to allow this file to still be accessible, while still password protecting the directory itself. So now the total thing looks like:


ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

# Allow WP-PostViews to access admin-ajax.php
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>

AuthType Basic
AuthName "Naje"
AuthUserFile "/home/userna5/.htpasswds/public_html/wp-admin/passwd"
require valid-user



Please let me know if you're still experiencing any issues at all!

- Jacob
Staff
5,534 Points
2013-07-15 1:18 pm
Hello pkonto, and thank you for your question.

I'm unable to replicate the issue you described here. If a user enters in invalid credentials, they will be prompted for the .htaccess password again and again until they hit Cancel. Then they should see the Denied message you have put in place with the ErrorDocument statements.

Continually guessing at the .htaccess password isn't too much of a risk as it's not CPU intensive, and much harder to automate than a login attempt processed by a PHP script like the normal WordPress admin login.

If you still had any questions at all please let me know!

- Jacob
2013-07-15 2:06 pm
Thank you so much Jacob! You are a genius:)
Staff
5,534 Points
2013-07-15 2:11 pm
Hey MarwaRakha!

Thanks for the kind words! Glad to hear it sounds like that's working for you. Let me know if you run into any further issues :)

- Jacob
2013-07-21 6:04 pm
Hi Jacob,

Thanks for the nice snippets.
I have a suggestion about naming the password file.

Instead of having "wp-admin/passwd" use "wp-admin/.htpasswd" because Apache will restrict access to files starting with .ht ... by default unless configured otherwise.

If the password file is downloaded the hacker may start iterating millions of combinations a lot quicker.

Slavi Marinov,
Swiss Army Knife for WordPress
http://club.orbisius.com/products/tools/swiss-army-knife-for-wordpress/
2013-07-21 6:23 pm
I made another update

RewriteCond %{HTTP_REFERER} !^https?://(.*)?$example\.com [NC]

e.g. to allow http or httpS
Staff
10,518 Points
2013-07-22 3:14 pm
Hello Orbisius,

Thanks for the suggestions! If you have any further suggestions, please keep posting them here. We appreciate the input!

Regards,
Arnel C.
2013-08-09 1:04 pm
Hello again Jacob
You have helped me in a comment above dated 2013-07-15 5:06 pm
Now I cannot access my dashboard. I get the following message
Error 403 - Forbidden

You don't have permission to access the requested resource. Please contact the web site owner for further assistance.

What's wrong?
Staff
5,534 Points
2013-08-09 2:19 pm
Hello again Marwa, sorry for the troubles.

I took a look at your access logs and reviewed your .htaccess files, and it appears that what's more than likely happening is that your IP address has changed. Because I don't see any 403 forbidden errors from the IP address allowed in your .htaccess file.

What you'll want to do is find your new IP address, and you can use our IP address lookup tool to find that.

Once you've got that IP copied you will simply want to replace line 15 in your .htaccess file:

RewriteCond %{REMOTE_ADDR} !^197.36.146.106$


You'll want to replace that line with your new IP address. Then after you do that, I'd recommend clearing your browser's cache to ensure you're getting the new .htaccess rules, then try to login to your WordPress admin section again.

If you're still having any issues at all after completing that, or you need any help doing so, please let us know!

- Jacob
2013-08-11 7:13 am
Thanks a lot Jacob! I followed your recommendations and it worked:)
Staff
5,534 Points
2013-08-12 1:58 pm
Hey MarwaRakha,

Glad to hear that worked for you!

- Jacob
2013-08-28 12:13 am
Hello Support

In following the steps, once I create the protected directory and save, accessing /wp-admin results in "The page isn't redirecting properly." I've continued with updating the public html/.htaccess file as described but still get a "This webpage has a redirect loop" in Chrome and "The page isn't redirecting properly."
Staff
5,534 Points
2013-08-28 11:50 am
Hi unpadgroup, sorry for the troubles.

I took a look on your VPS and see that you have quite a few WordPress sites that are actively triggering our security rules, some as high as 23,000 times. So it's a good thing you're looking at implementing this extra layer of protection.

I guessed which site you were having these re-direction problems with based off .htaccess files being modified in the last 2 days, and went ahead and fixed this for you.

The problem is the same one highlighted at the top of this article regarding missing the ErrorDocument definitions in your .htaccess file.

Let us know if you continue to have any issues?

- Jacob
2013-11-07 8:09 am
Hello Jacob,
I'm stuck at step 9. I've called in and it seems to have stumped the folks at InMotionHosting so far. Any tips? My website is just for today meditations dot com, and the wp admin login is stuck in a redirect loop now that I've applied a password to the directory.
Thanks for your help.
2013-11-07 8:11 am
Also - I tried to do step 11, and I don't see a .htaccess file in the wp-admin folder in the File Manager. I only see that file in the main folder.
Staff
10,075 Points
2013-11-07 10:59 am
Hello nettaP,

I do see a .htaccess file in your wp-admin folder. I then added the following code to the top as stated in the article just above the steps:

ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

That seems to have done the trick for you. You should be able to get through the password popup to the wp-admin login screen now as my test here was successful.

Kindest Regards,
Scott M
2013-11-10 1:05 pm
Scott - thank you so much. I'm trying to do the same thing on the .htaccess file for xoxo netta p dot com, and I think I must still be doing something incorrectly. :( Could you help again? Thank you so kindly.
Staff
5,534 Points
2013-11-11 2:14 pm
Hello nettaP,

As is mentioned in the top of this article about the re-direct loop, and also what Scott responded with. It looks like your .htaccess files were missing the ErrorDocument lines causing your re-direct loop.

I went ahead and added these as described in this article to the top of your /public_html/.htaccess file as well as your /public_html/wp-admin/.htaccess file, and now you should be able to log in.

If you're still having any issues at all, please let us know.

- Jacob
2013-11-17 10:41 am
I have followed your instructions with the exception steps 8 and 9 as I still can't access my site. I am getting:

The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@dielleciesco.theunknownmother.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log. Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

Help!
2013-11-17 11:49 am
And while I'm asking, is this going to mess up things for my moodle users?
Staff
4,023 Points
2013-11-18 11:02 am
A 500 error is caused by some sort of error within your code, in this case it appears to be within your .htaccess file based on the modifications that are explained in this article. I recommend looking over your .htaccess file for any errors or possibly starting over from scratch. Contacting technical support will also be able to provide you with specifics as to what is generating the error.
2013-12-15 2:40 pm
I just followed each and every step and when I click on any link or article on my blog, Similar wp-admin PopUp comes. although /wp-admin is locked but Popup comes each and every time i click on any link... any solution for this.. right now I have removed password protection of admin folder
Staff
4,023 Points
2013-12-16 9:26 am
It sounds like you have some port of rewrite within your .htaccess that is causing everything to be appended with /wp-admin. Take a look within your .htaccess file for any issues as well as try renaming your .htaccess file to see if the issue goes away.
Staff
5,534 Points
2013-12-16 4:19 pm
Hello ebuzznet,

Sorry to hear that you were having issues with the WordPress admin .htaccess password protection.

Taking a look at your site, and your access-logs, it appears that you have a plugin that is continually trying to POST to /wp-admin/admin-ajax.php whenever an article is loaded. This in turn is triggering the .htaccess password protection that you had setup, causing the password pop-up each time an article is attempted to be viewed.

Another user higher up in the comments was also having this issue, and we were able to resolve it by allowing POST attempts to the /wp-admin/admin-ajax.php script to bypass any sort of password protection. The resulting rules would end up looking like this in your /wp-admin/.htaccess file:

ErrorDocument 401 "Denied"
ErrorDocument 403 "Denied"

# Allow access to /wp-admin/admin-ajax.php
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>

AuthType Basic
AuthName "admin"
AuthUserFile "/home/userna5/.htpasswds/public_html/wp-admin/passwd"
require valid-user


As you can see I've added a <Files admin-ajax.php> section to the /wp-admin/.htaccess file rules.

If you're still having issues with the .htaccess password prompt continuing to show up on your articles after implementing this change, please let us know!

- Jacob
2013-12-30 6:32 am
Far better if you'd let us customize wp-login.php to wp-blahblah-custom.php . The spammers would have a lot harder time hitting such a site. I'd have more trouble remembering it, but hey, that's what support is for ;-).
Staff
4,023 Points
2013-12-30 10:24 am
Hello bnesbitt,
You can change the URL to your WordPress admin, but it can take quite a bit of custom coding to eliminate any issues from it and can vary based on the particular site, as well as could cause issues with upgrades in the future. Hopefully, WordPress will build this feature into their software in the future.
2014-01-28 4:50 pm
I have followed all steps and I still get the login prompt when viewing the front end of the site. I added the rule to avoid this but it still happens.
Staff
5,534 Points
2014-01-28 7:36 pm
Hello tacudtap,

Sorry to hear that you're having issues still receiving the password prompt on the front-end of your site. You might want to try to clear your browser's cache to ensure that your computer isn't caching your old .htaccess rules.

If you're still having issues, please email support@inmotionhosting.com for further assistance. Or if you'd like help from us please provide us with the domain name you're having these problems on as unfortunately the email addressed you've registered with our support center is not linked to any active hosting accounts so we can't see this information currently to lend a hand.

- Jacob

Post a Comment

Name:
Email Address:
Comment:
Are you a bot?
Submit

Please note: Your name and comment will be displayed, but we will not show your email address.

Write New!
Do you want to publish a tutorial to our support center?

News / Announcements

SSL Certficate Warnings
Updated 2014-04-14 11:34 am EST
Hits: 2000
Heartbleed 0-day OpenSSL security bug
Updated 2014-04-14 04:43 pm EST
Hits: 5273

Related Questions

Here are a few questions related to this article that our customers have asked:
Ooops! It looks like there are no questions about this page.
Would you like to ask a question about this page? If so, click the button below!
Ask a Question

Need more Help?

Search

Ask the Community!

Get help with your questions from our community of like-minded hosting users and InMotion Hosting Staff.

Current Customers

Chat: Click to Chat Now E-mail: support@InMotionHosting.com
Call: 888-321-HOST (4678) Ticket: Submit a Support Ticket

Not a Customer?

Get web hosting from a company that is here to help. Sign up today!