Make WordPress Core

Opened 14 years ago

Closed 11 years ago

Last modified 11 years ago

#13118 closed enhancement (duplicate)

wp-login.php and wp-admin folder location/name choice during the installation

Reported by: msnexus's profile MSNexus Owned by: dd32's profile dd32
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: Cc:

Description

I thing to make WordPress more secured, it is important to let WordPress users change thier "wp-login.php" file and "wp-admin" folder names/locations during the installation of WordPress.
So here is an example, by default my WP login site is:
"myverypopularwordpresspoweredwebsite.com/wp-login.php" but I changed that to "myverypopularwordpresspoweredwebsite.com/secure-login" so if someone comes to "myverypopularwordpresspoweredwebsite.com/wp-login.php" - than that person just got a 404 - Not Found website.

I thing that´s very important to make WordPress more secured, because links like "/wp-login.php" and "/wp-admin" are very easy to know for WP users and potential hackers.

I know there is lots of plugins to do that, but there are too out of dated and doesn´t work at all.

I am also now using WP just for my blog, but I want to power my big website about fantasy/sci-fi by Wordpress, (now powered by Drupal).

I thing that would be just usefull and a great new feature of WP 3.0,

So many thanks to all developers and all WP community,

Change History (14)

#1 @nacin
14 years ago

  • Component changed from Filesystem to Administration
  • Milestone changed from 3.0 to Unassigned
  • Priority changed from high to normal
  • Severity changed from critical to normal

There are plenty of ways to lock down login and admin, ranging from moving them (yeah, it's possible), locking them down at the server level by IP or HTTP Auth, forcing SSL, etc.

Security by obscurity is nothing more than a house of cards.

New ideas belong in the ideas forum: http://wordpress.org/extend/ideas/.

#2 @dd32
14 years ago

  • Milestone Unassigned deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I agree with nacin in this case, Security by obscurity is not something that need be encouraged, proper security should be applied instead.

I'm closing as wontfix for now, Feel free to raise this on the Ideas forum, or on wp-hackers mailing list for more input. At this stage, this is something that would be best dealt with at a server-level configuration IMO. Being able to locate the login form will not prevent 99% of attacks.

#3 follow-up: @gazouteast
14 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I have been asking for a long time for a simple triple define in wp-config.php to set the names and paths of the three main wordpress wp-* folders.

This is a basic and foundation level security measure to delay / divert hackers.

The entire code base should be pointing to those three paths via constants, and the paths for those constants should be definable. If set during install rather than in wp-config, the true paths could be saved in the database as MD5 hashes, making it even tighter.

Security by obfuscation is not a house of cards, it is an additional layer. There is nothing to stop (and it would be recommended to do so) having dummy folders retained with the original wp-* names, password protected from cPanel / Plesk etc as a frustration to hackers, who might then focus on cracking to get into empty folders while ignoring the real and obfuscated locations. During which time, server logs would tip the hosting service or site admins that something was happening.

I think it is disingenuous of WordPress to shun this measure, when even scripts like osCommerce have had it for seven or eight years already - see also discussions on Mark Jaquith's blog post regarding hosts need to get with the WordPress hosting requirements, and the many angst comments about flawed WordPress security coding.

You're missing a real opportunity to tighten ship here guys, and with the most minimum of effort.

Gaz

#4 in reply to: ↑ 3 @wpmuguru
14 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Replying to gazouteast:

Security by obfuscation is not a house of cards, it is an additional layer.

All three paths can be obtained from the front end of a site by a non logged in user. Obscuring them as you have proposed would not provide any increased security.

If you are interested in additional security for your site(s), you should consider investing in SSL certificates which can be used with both your login form and admin area.

#5 @carlocapocasa
11 years ago

  • Cc carlocapocasa added
  • Keywords changed from wp-login,wp-admin,wordpress,secure,more to wp-login wp-admin,wordpress,secure,more
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Type changed from feature request to enhancement
  • Version 2.9.2 deleted

While "security by obscurity" is indeed a house of cards, it has been confused in this thread with "obscure url", which is actually a perfectly valid security technique that is just as good as using a password. Only the name is similar, not the concept; "obscure URL" is equivalent to including a security token in a REST API call.

To make it work, the obscure URL component needs to be chosen like a strong password. Examples:

No additional security:

http://my-site.com/my-wp-admin

http://my-site.com/admin

http://my-site.com/nancy-admin

Full additional security layer:

http://my-site.com/wp-admin-1m1f9ioz8hr3qljr

http://my-site.com/admin38wtfet39nz5rubh

http://my-site.com/o1b7uv8n7twdcrpb

Of course it would be a perfectly sound management decision to keep this on 'wontfix' to avoid the risk of breaking things or to focus the labor elsewhere, but the commenter thinks it would be a great idea to re-evaluate the decision in those terms and weigh it against the benefit of having the option of using "obscure url" instead of baseauth (or additionally), given the two provide equivalent security.

Pros of obscure url:

  • Less hassle for users than baseauth, good for "friendly security"
  • Can be implemented without admin access, lowers the barrier for small companies or individual bloggers to harden their install
  • Can be done in addition to baseauth and the regular login if desired
  • Bots give up without trying to brute-force the login, reduces log spam

Cons of obscure url:

  • Implementors need to know how to chose the URL, the same way they need to know how to chose a strong password
  • Users need to know they must keep the admin URL secret, the same way the need to know they must not share their passwords
  • The browser keeps the secret URL in history by default, so users need to know to delete their history on public computers, just like they need to know they should't allow their passwords to be saved on public computers
  • Oddly, it is not a very widely known technique except for APIs, so a little explaining might be required along the way.

#6 @alexvorn2
11 years ago

  • Keywords changed from wp-login wp-admin,wordpress,secure,more to wp-login wp-admin wordpress,secure,more

you don't log in into Facebook : facebook.com/wp-admin-1m1f9ioz8hr3qljr right?

or gmail: http://gmail/o1b7uv8n7twdcrpb

Version 0, edited 11 years ago by alexvorn2 (next)

#7 @alexvorn2
11 years ago

  • Keywords wordpress secure more removed

#8 @nacin
11 years ago

If you want this kind of security, rather than the random URL, use basic HTTP authentication, or add an authentication method (two-factor).

I'm not sure if we will implement in core the ability to rename wp-admin, but if we do, it A) won't be done for security reasons, and B) won't be done anytime soon. This remains a strong wontfix in my book.

#9 follow-up: @alexvorn2
11 years ago

I think that for now there is only one big problem in security: e-mail, if someone got access to your email he can get access to the site! That's where we should add something not here.

Last edited 11 years ago by alexvorn2 (previous) (diff)

#10 @SergeyBiryukov
11 years ago

  • Keywords wp-login wp-admin removed
  • Resolution set to duplicate
  • Status changed from reopened to closed

Duplicate of #7194.

#11 in reply to: ↑ 9 @johnbillion
11 years ago

Replying to alexvorn2:

I think that for now there is only one big problem in security: e-mail, if someone got access to your email he can get access to the site! That's where we should add something not here.

That requires a two-factor authentication mechanism, which is definitely plugin territory for the foreseeable future (and there are quite a few plugins which provide this functionality).

#12 follow-up: @carlocapocasa
11 years ago

Okay guys thanks for hearing me out. I didn't hear any kind of valid technical argument against obscure URL for security here, so in case there is an interest to follow up with that for sake of getting to the bottom of it, I'm all ears.

In case someone arrives here looking for a solutions, I ended up giving WordPress its own directory as in http://my-site.com/1m1f9ioz8hr3qljr/wp-admin, which is good enough for me.

#13 in reply to: ↑ 12 @alexvorn2
11 years ago

Replying to carlocapocasa:

Okay guys thanks for hearing me out. I didn't hear any kind of valid technical argument against obscure URL for security here, so in case there is an interest to follow up with that for sake of getting to the bottom of it, I'm all ears.

In case someone arrives here looking for a solutions, I ended up giving WordPress its own directory as in http://my-site.com/1m1f9ioz8hr3qljr/wp-admin, which is good enough for me.

this does not help to hide the location of the wp-admin page

your style.css file will be located in my-site.com/1m1f9ioz8hr3qljr/wp-content/ ... /style.css and this information from the html source code is enough to get the wp-admin page, as it is: my-site.com/1m1f9ioz8hr3qljr/wp-admin/

:)

#14 @carlocapocasa
11 years ago

Good that you mention it-- I'm using a custom theme and server URL rewriting, so the combination does the trick. But you're right, non-technical WordPress users, or those short on time, can't do that.

Last edited 11 years ago by carlocapocasa (previous) (diff)
Note: See TracTickets for help on using tickets.