Hi Mike,
Currently, we do not offer an option to hide the login page. We feel that hiding doesn’t really address the main concern of keeping unauthorized people or bots out of a site.
Thanks,
Brian
My clients feel a lot more confident accessing a friendly address, such as /panel or simple /admin
Please add this feature so we can stop using another plugin just for this 😉
Thanks in advance
=)
Thanks for the feedback. This may be considered for a future version of Wordfence, but it is not planned for a specific version, if it will be implemented.
-Matt R
This, along with the rest of the protection WF provides, is a great idea.
If the commonly known place to “attempt” exploits cannot also easily be found this very well could reduce the amount of email notices in addition to possibly dropping your domain from the attackers list…if of course the attacker themselves has an efficient mechanism of qualifying targets.
Of course, you’d need to kill the built in core method of redirecting the default /wp-login.php to the newly defined login path.
Edit: Just to add more clarity here. I have tried a few things to minimize my websites exposure and the hundreds of emails I receive daily…ultimately if I can find a way to not expose the actual login form maybe that will have some effect on the actual traffic hits too.
Here’s where I’m at so far:
1. I have wordfence installed and am actively blocking any invalid usernames as well as X number of failed attempts.
2. I have the Clef two-pass plugin which replaces the wp-login form removing the ability to login with a username/password altogether.
3. I have XML-RPC completely disabled and have confirmed by testing with the WP mobile app – no access
4. I have written a redirect plugin that unless you type in an exact and very obscure url w/ post data and matching key, you are redirected back to the home page i.e. http://www.mysite.com/wp-login.php?someobscurestring=myobscuredayakey
What else am I missing? How else do I prevent these attempts?
It’s unlikely they would figure out my redirect bypass and it appears that clef simply hides the traditional form rather than rewrite it, so technically its still there and served up with wp-login.php and I suppose post data is really the problem here?
Is it maybe that post data is still capable of submitting the core login form behind all of these preventative measures before my redirect kicks in?
Yes, if Clef only hides the login form that appears on the page, it shouldn’t affect whether or not logins can be attempted, unless they also hook into the login process in WordPress. I can’t help with the custom redirect plugin you mentioned, but I can mention to the dev team that there is more interest in this option to change the login URL. Thanks for your input!
-Matt R
