[wp-trac] [WordPress Trac] #24673: provide mainline supported rename of wp-login

[WordPress Trac]

#24673: provide mainline supported rename of wp-login
--------------------------+----------------------
 Reporter:  jorhett       |       Owner:
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Security      |     Version:  3.5.2
 Severity:  critical      |  Resolution:  wontfix
 Keywords:  close         |     Focuses:
--------------------------+----------------------

Comment (by jorhett):

 First of all, thank you for responding seriously. Please read this all the
 way through and take my comments seriously. I'm trying very hard to
 refocus this usefully.

 Replying to [comment:34 TobiasBg]:
 > However, I also think that this suggestion is no "one-size-fits-all"
 solution, and that potential issues that this could cause for
 inexperienced users far outweigh the benefits -- even if it were not a
 mandatory but an optional feature.

 I think the main problem which has plagued this discussion is False
 Dilemmas like this. Each person says "well if we do X (which nobody
 proposed) it would suck worse, so the current situation is better".  The
 point of discussion is not to shut down proposals but to encourage them. I
 can think of a half dozen solutions with zero impact on inexperienced
 users that are better than what you have today -- but can't even get them
 out before someone throws another false dilemma out and closes the ticket
 again.

 > Most sites (especially those with many authors/editors) just won't work
 with a secret login URL that no user can remember. They will then simply
 choose common URLs like "admin", "backoffice", or whatever, so that we are
 back at the initial problem.

 False Dilemma. Nobody has suggested this is a good idea.

 > Due to those mentioned drawbacks, this approach simply is not suitable
 for general inclusion into the WordPress core.

 I agree. Nor do I recommend using oreos and milk as an authentication
 mechanism, which is about as good as what's been tossed out so far.

 Every "solution" presented in the False Dilemmas are not suitable for
 general inclusion. Furthermore, I would say that not a single one of these
 addresses even half of the issues raised so they aren't any better than my
 oreos and milk proposal to start with.

 > With 2FA and HTTP Auth, two popular and working mechanisms for
 increasing protection against botnets have been mentioned in this ticket.
 Besides that, there are plugins available to change the login URL, so any
 admin who is worried about botnet attacks is free to install those.

 The hysterical thing here is that everyone bows on the altar of not
 breaking user expectations, existing applications, or making it hard for
 newbie users -- and yet both of these solutions break all three. Very few
 newbie users can enable HTTP auth on their sites, and no applications
 support either of these solutions. Why are these acceptable, but proposals
 which wouldn't break all three are unacceptable?

 Let's talk about real proposals here -- I'm not saying this is perfect,
 I'm saying that it has been used successfully by many interfaces to limit
 the effects of bots:

 Shared (or user-unique) Tokens:

 * Login pages which aren't provided with the token shortcut to an error,
 thus limiting damage
 * Users can follow a multi-factor authentication to gain/regain a token
 stored in cookie/app/etc for easier return
 * Admin logins won't succeed without a token, period.

 Bam: you have minimized effort on wp-login, you've completely shut down
 wp-admin without the token, and you didn't move your login pages. The same
 token could be used for RESTful auth endpoint, likewise limiting effect.

 Flexible page paths:

 * All the site admin to adjust the login/auth locations
 * Allow distinct user/admin login locations if desired
   -- such that user login has a link on the site anywhere in the template,
 but admin pages not
 * Easy command line or MySQL retrieval of page locations (duh!)

 Both of these could be combined for easier usage. Certainly if the
 login/admin page links were available to be anywhere in the style without
 consistent formatting around them, then automated parsing becomes
 exponentially harder.

 Both of these could be useful and neither would break user expectations. I
 must run to a meeting, but I know that we can do better, if we stop
 throwing out false dilemmas and start thinking about ways to make it
 actually better.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/24673#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform