[wp-trac] [WordPress Trac] #24673: provide mainline supported rename of wp-login
WordPress Trac
noreply at wordpress.org
Tue Apr 1 22:23:09 UTC 2014
#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
More information about the wp-trac
mailing list