[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 nacin):

 jorhett, the idea you originally proposed here — renaming login and admin
 locations — was widely panned and flatly rejected. It is not the first
 time we've heard the idea, so pardon us (honestly) if we were glib in
 dismissing you. Additionally, your words in this thread are fairly
 despicable for someone who is seeking to be respected. You keep saying
 "false dilemma" over and over again, so surely you are familiar with other
 fallacies, such as "ad hominem"? Pretty much everyone here responded
 seriously, and you decided to just attack people. In one particular case
 tell them to stop responding, despite his best efforts to contribute and
 understand.

 Perhaps we are unique among the open source projects that you have
 contributed to in a project leader's extremely low tolerance for someone
 being a complete asshat. That is your problem; not mine.

 If you do that again, you will not be welcome here, period, I don't care
 what you're trying to contribute. Stop tossing around insults like you're
 better than us. I don't really care if you are; you very well may be. But
 I will not tolerate attacks on ''my'' contributors. That's what I have a
 problem with.

 ----

 So, look, your idea is bad. There are a multitude of reasons, but one in
 particular that resonates with me is it'll keep users out just as much as
 bots, and it'll mean bots just have to guess what will probably be a
 fairly short subset of URLs, just as users will have to guess where they
 put their own dashboard, too. Preventing all bot activity isn't worth it
 if it means there are no users, or no happy users. We are not going to
 make it so people can customize the login and admin URLs in WordPress
 core. It is not happening. You don't understand how changing where a user
 logs in will "break user expectations", so I expect you to respond to this
 entire paragraph with two words, "false dilemma." So be it. It seems the
 only way we will understand your genius is if you write a patch or a
 plugin that implements your proposal. I'm done seeing time wasted arguing
 in a circle.

 As a lead developer, it is taking me far too much time to parse what the
 hell you're trying to say, which is another way of me saying I am finding
 it to be incredibly convoluted. I usually try to avoid demanding code to
 back up an idea, but at this point we've wasted a few thousand words on
 this it's time for something less abstract. Diagram it out, code it up,
 something, anything, so we have a better idea of what you're proposing.

 Some of us have been doing this for a long time and we're aware not only
 of the gravity of the situation, but we're also very experience in
 building massively distributed software for an incredibly diverse user
 base. This situation essentially means that finding a golden solution for
 this is near impossible; it is not one-size-fits-all; and anything we have
 brainstormed over the years wouldn't work for a significant minority of
 users and/or would be worked around by any bot owner with half a brain. As
 it is, trying to solve a botnet at the application level is not exactly
 the best approach. We have no desire to get into an arms race with these
 people. We are either going to let this be solved by plugins, networks,
 and hosts; or we are going to implement a perfect solution.

 On the bright side, it ''seems'' your idea has evolved from just hiding
 the location of the admin area and into a more complex idea using words
 like factors and tokens. This is great, as latching onto a single solution
 without a clear definition of the problem or without consideration for the
 ton of other variables is not helpful.

 You probably don't think your idea has evolved at all. I have re-read the
 entire ticket, as you have so unhelpfully ordered everyone to do. I found
 that the original proposal contained unexplained contradictions like the
 "botnet provider keeps learning with each new evolution" but that they are
 powerless against "dynamic information". If you are wondering why your
 idea was rejected nine months ago, look right there. You are now
 mentioning tokens and multiple-factor authentication, which is good. I
 still do not understand "if it was just text on the screen, he couldn't
 very well alter his botnet to parse the text and figure it out".

 Now, a token is still a pretty convoluted user experience. And isn't a
 token in this regard a "password"? As in, a second password, or a second
 factor? If you're going to open the door to talk about multiple factors, I
 would be happy to move beyond playing shell games with the login page and
 actually have a discussion about *real* multiple factor authentication.

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