provide mainline supported rename of wp-login

[jorhett]

In general I mock people who do security through obscurity, but I think in this case it might help a great deal. It's not that Wordpress needs obscurity, so much as Every Wordpress Is The Same and we've made the attacker's job way, way too easy.

We are in our 4th month of ongoing and escalating botnet attacks. The botnet provider keeps learning with each new evolution, and we're seeing a new evolution each week.

One thing a botnet can't do is deal with dynamic information. If Wordpress were to provide a mainline, supported mechanism for a unique login URL, this would stop the botnet flat. Obviously this would require that you can't issue a remote query to get the login URL. But if it was just text on the screen, he couldn't very well alter his botnet to parse the text and figure it out. Or maybe he could, but it wouldn't work nearly so often.

I believe this is a problem best solved at the source. In a small, simple code fix that doesn't require every wordpress site to install large complex plugins to achieve.

[mark-k]

If I navigate to example.com/wp-admin I am redirected to the login page url, so in order for your idea to work, if I got it right, you need to change also the wp-admin path to be dynamic.

Basically what you want to create is a second password that a user has to remember in order to be able to login, a password that will be set automatically by the software. How will the recovery process work if a user forgets this password, and how will it work when there are multiple users?

[SergeyBiryukov]

Related: #13118, #7194.

[jorhett]

How about the login link on the home page of the site, just like most sites today? That is hardly a password...

In fact, this is the core of my argument. There are a few plugins out there that hide the login page. That works well for sites with a few admins, who can bookmark the new login page. But sites where user login is encouraged need an easy public, visible login page. Themes need the ability to get the login url through a function call.

The botnet code isn't doing something complex like evaluating the HTML of each site to find the login URL. For highly customized sites that would be very difficult to determine. The botnet code is super simple, because Every Wordpress Site Is The Same. Just being able to move the login url(s) around would shut the botnet down considerably. You can easily do this, without making it trivial to determine externally.
(yes, trivial for a human but it isn't a human attacking here. If we can make him use 10,000 humans trying to find URLs all day long, then we have succeeded in stopping his attack)

[jorhett]

It would also be trivial to document how to recover the site's login URL, if an admin were to change the login url and forget it, while using a theme that doesn't have a visible login URL... but honestly, there are a lot worse things you can do to your Wordpress instance today while being less stupid than that :)

[mark-k]

Replying to jorhett:

The botnet code isn't doing something complex like evaluating the HTML of each site to find the login URL.

citation needed. spam bots were solving gmail captcha some time ago, why can't they do simple extraction from HTML?

Anyway changing the url of the login will not help without also changing the url of the XML-RPC endpoint as well.

[nacin]

I don't think we'd want to do this. A plugin or sysadmin can do so if you want. There are better ways to prevent denial of service attacks (at both the PHP and network level) than this. Give it a few months and such bots will get smarter. This arms race will simply damage integrations with WordPress (including applications; note mark-k's note re: XML-RPC) and expectations of users. WordPress should not have UI options that make using WordPress more difficult.

It is already difficult enough for users to remember URLs like wp-login.php and wp-admin, which is partially why we added /admin, /login, and /dashboard redirects in 3.5. And especially so if you have multiple installs. That would only be made worse with arbitrary locations.

[iseulde]

I agree with nacin, I should be up to the admin to decide how they want to secure their login page.

That said, I released a ​plugin a few weeks ago that ‘changes’ wp-login.php to something else. It doesn’t break anything, all the forms work properly, the login widget and all login links work, and expired sessions work too. wp-login.php will return a 404 status, and so will wp-admin if you’re not logged in (there’s no redirect).

You could use it just to have a nicer login url, or to hide it, as if you had a second password. The only thing the plugin doesn’t do is hide login links on your website (if there are any), that’s up to the admin to decide.

Suggestions are always welcome!

[SergeyBiryukov]

#27611 was marked as a duplicate.

[nickadamstv]

How about having something that's built into core but, just like a lot of other things, is just an available option? That way nobody is forced to do anything that they don't want to do, but every user has the ability to change the login URL and hide wp-admin with no redirects without having to install yet another plugin. Giving them the ability to set their own chosen URL instead of a system generated one should, also, hopefully, make it much easier to remember, which would resolve the above stated concern about accidental lockouts due to forgetfulness.

[nacin]

Replying to nickadamstv:

How about having something that's built into core but, just like a lot of other things, is just an available option?

Aside from the raw benefits or drawbacks of the ability to move wp-login.php (which I find are limited and plentiful, respectively), adding an option would go against most of our philosophies outlined at ​http://wordpress.org/about/philosophy/, including "decisions, not options," "striving for simplicity", and "design for the majority".

[jorhett]

Replying to nacin:

Aside from the raw benefits or drawbacks of the ability to move wp-login.php (which I find are limited and plentiful, respectively), adding an option would go against most of our philosophies outlined at ​http://wordpress.org/about/philosophy/, including "decisions, not options," "striving for simplicity", and "design for the majority".

A login page URL at an expected location for a given user community is simpler than one which is forced upon them and inconsistent with their site design. I see no value that every wordpress site should be the same as every other.

And for "design for the majority" if you mean "design for the majority of wordpress sites to be hacked" then yes, you have succeeded. You are the *ONLY* CMS that has your own Botnet. Yes, you are a leading CMS but you are the absolutely world leader with no competition in hacked sites.

The goal here is to allow people to avoid the super-simple attack script which has turned wordpress sites world over into a botnet army used repeatedly to attack others. To invalidate the 90k hits per day on average received on each and every wordpress site trying to find password combinations.

This is a very simple problem with many elegant solutions, but you won't consider them. I'm curious about when you'll be named as a defendant by one of your victims.

[knutsp]

When I navigate to /wp-admin, without being logged in, I expect to be redirected to the login page. When I enter my credentials I expect them to be posted to the login handler and be redirected back to wp-admin as a logged-in user. Do I have to know there is a wp-login.php that handles this? No.

So if I don't need to know about it, why should an attacker?

This suggestion isn't even obscurity. It's like moving the front door of a house to some odd place around the corner, and have a sign pointing visitors to it, all just to try to avoid burglars. They are not that stupid.

Renaming wp-login.php will for sure avoid a lot of attacks to that specific site, for a while. If core did that this it would help for a few weeks, until the scripts get just a little more sophisticated, following a simple redirect. They don't bother to do that now, because there is no gain. But they will, and it will happen immediately.

This works like placebo. A lot of people report that it "works". But when given to all that has the disease it is no cure.

What core could implement is enforcing even stronger passwords and limit login attempts. Excellent plugins already do that.

[jorhett]

Nobody suggested what you just said. This isn't a binary problem space. Your accusation is a false dilemma proving only that you don't understand the problem space.

1. Why does every site need to use wp-admin? Is there some clear value in having every WP site use the exact same login url? Sure, it can be a default -- but forcing it on everyone means that it breaks many sites with their own well-designed layout.

So if we don't put it at wp-admin (or wp-login for the obvious other case) then how will they know to find it? They can plunge the ocean hoping to find their way to the admin page... which requires too much resources.

2. Why is the user login and the admin login the same? Allow them to be distinct. You must provide an obvious user login page. You can limit the admin login page to those who know where it is.

3. Why not allow a 3rd mechanism? User, password and something else depending on the plugins available. You allow plugins to control user/password, but don't allow true freedom for alternative security mechanisms. I could easily use hard/soft tokens for auth for any admins to my personal sites. We have the technology...

This is why there are bots to break into Wordpress, and not bots to break into other CMS. You claim they'll easily find their way to an unknown page with no links to it. I call fooey, because if there was then there would be botnets for Drupal, Joomla, etc. There aren't for exactly this reason.

Stop with the false dilemma, and acknowledge the 70+ K botnet of wordpress nodes used for criminal activity.

[nacin]

At some point fairly soon, there's going to be a proper REST API to replace the existing XML-RPC API. Both of them require centralized authentication. Over time, a new API is going to be full-featured, and it'll eventually probably power the WordPress dashboard. This proposal cannot be squared with having a public API available to the world's applications to consume data from WordPress sites.

Us playing "pin the tail on the login page" is a terrible experience that's going to keep users out as much as bots. It's not something we're going to add to WordPress core. If you want to actually be more secure, stop screwing around with hiding public URLs and add real two-factor authentication to your site.

Yes, WordPress is a huge target. We're very cognizant of that. But this isn't something we're going to add to WordPress core. We have a rich plugin architecture for exactly this purpose. There's nothing wrong with discussion continuing here, but the ticket can remain closed for that to happen.

I would much rather work out a way to bake in two-factor authentication (with what second factor, I don't know) or some prevention of brute-force attacks. This has been previously proposed at #24193, but is really, really difficult to get right at the application level; it should really be solved at the network/host level instead. Improving the security of sites is a big challenge but this one is not happening.

[knutsp]

The reason WordPress is more attacked by botnets has to do with the bigger target. Malicious hackers always goes for the bigger targets first, the easiest way. This doesn't mean that making it just a bit more difficult to do "brute force" will change this. A way to "protect" WordPress could cynically be to stop the development, making the target smaller and others CMS's bigger.

This ticket is about changing "wp-login", as the description says. That is not going to help.

Changing the wp-admin part of the admin url is another thing. Setting it to a secret would introduce another kind of password, at least if you are not able to be redirected to it automatically.

Introducing just "another password", in principle, is no way as long as it's purely web based. You may achieve the same degree of complexity by a just stronger password. A third party mechanism is the way here, requiring another device and address that the user has access to, like a mobile phone.

A weak or medium strong password may not withstand a brute force attack that is allowed to go on forever. This is the actual weakness, along with allowing weak passwords at all.

Ticket #24193 suggests limiting the ability to do some brute force attacks.

The main points is, that what works for a lot of sites, in ways of avoiding botnet attacks, is not necessarily what WordPress core should do. And what WordPress core should do is not making it difficult to log in to their own WordPress. What WordPress does best is to allow almost any modification through plugins. So when someone wants to stand out, being different, maybe harder to "get" by common means, use or make a plugin.

[jorhett]

I am deeply amused by people with no apparent knowledge or experience with security mechanisms making all sorts of claims about what actually improves security. This goes back to what I said before -- it's false dilemmas created by suggesting a false effort and comparing it to the current, with even more joy added by making allegations about what increases security that defy actual statistical analysis.

Saying it because you believe it, does not make it truth. There is extensive history of security mechanisms that proves that *ANY* third factor improves security significantly. Granted that crypto-based hardware tokens are better than shared keys/salts, but not half as much as you might think.

Furthermore, testing of "strong passwords" has generally proven that human limitations of what they can and will type into their devices combined with a strict limitation of acceptable characters produces *EASIER* to crack passwords, not harder ones.

So please get off the "it ain't better because I said so" and consider real options. The REST API could just as easily have a configurable endpoint and/or extendable auth mechanism. I build these things daily, this would be trivial for you to support.

If you build it with a single termination point, just like you've built your current auth mechanism, you'll continue to be the market leader in p0wn3d sites. You have ~50% of the CMS market at best, but >90% of the p0wn3d sites. When is that going to matter to you?

[jorhett]

And let's get straight to the point: knutsp -- back up your claim that making it harder for a botnet to succeed won't make it go away. Show me your LinkedIn job profile and describe the positions where you were responsible for fighting off a Botnet.

Here's mine: ​http://www.linkedin.com/in/jorhett

I've fought off Botnets at every single job I've had in the last 17 years. I've been carrying, using, and designing from scratch hardware and software-based authentication mechanisms, and evaluating security vendors and solutions for 20+ years. In most of these jobs Security and Infrastructure were my primary roles, and I was either the most, or equal to the most experienced person on staff in that capacity.

I've thrown down. Now back up your expertise, and show me where you base your opinions from. Because every word out of your mouth defies both all my experience, but all statistical analysis of security mechanisms.

Nacin: I like Wordpress, I really do. But I grow excessively tired of coming home to fight off botnets on my personal websites. Please take this situation seriously, and stop blowing it off to add more cute UI elements while we suffer from your poor authentication design.

[knutsp]

I'm not in the game of fighting botnets, and thought this was about WordPress, not you and me and our merits in a field.

I wrote my last comment at the same time nacin did, and I see that we are pointing out much of the the same. Attacking me is probably an easier target for you, jorhett. Go for the weakest one who dare contradict you, the expert. Thanks for pointing out your excellence in the field of fighting botnets. I'm more into improving WordPress. I have zero merits in combat, just running WordPress sites. Sorry to have offended you, jorhett. I'm sure you know best. The debate may suffer, though.

[jorhett]

knutsp: The debate suffers because you have again switched tactics and now play the offended victim.

The entire purpose of this ticket was to stop the botnet. That was the cause for the ticket to be opened, if you were to read up. You have made numerous claims about what will or will not improve security, and as it turns out you have no basis for these claims (as I predicted). The debate will not suffer by your absence ;-)

Can we now discuss actual solutions to the botnet?

Nacin: your statement " This proposal cannot be squared with having a public API available to the world's applications to consume data from WordPress sites." holds no water. You could quite easily have a customized REST endpoint which is stored in the local DB and utilizes a 32bit UTF-8 charset which would be beyond the reasonable means of most botnets, and absolutely beyond what I have witnessed from botnets to date. The same endpoint could be registered in any browser, tablet, etc which needs access. So to your point, a dashboard which uses a REST endpoint would be EASIER to secure than your current implementation.

And back to now: the ability to shift the current login endpoint would provide a temporary respite while you build out the REST interface...

[knutsp]

The entire purpose of every ticket here is to improve WordPress. WordPress should not be in the combat against botnets, trying to make their attacks a bit harder to do. WordPress should try to make them less successful in breaking WoprdPress sites, without harming users.

I'm not out of a debate because someone attacks me and making points of own merits, wanting to having me shut up. I may be wrong, but not just because someone claiming to know better.

I want WordPress to be hardened, security wise, but this suggestion is just silly. The one who has to backup a claim is you, jorhett.

[iseulde]

1. I made this plugin primarily because I wanted a custom login url and, secondly, because one small hosting company in Belgium decided to block wp-login.php with a Captcha (I'm sure there are others). I have zero experience with security, and the reasons I made this plugin have more to do with aesthetics than security.

2. While this plugin *should* make it impossible to get to the login page without "a second password" (because that's what it really is, how simple it may be), there are some other APIs that could be attacked instead, such as xmlrpc.php. Renaming things like that would just cripple your WordPress install. And if you don't need it, you can simply turn it off as an administrator. As nacin said, a lot more public APIs are going to be introduced.

3. Giving the user the option to rename wp-login.php without and easy option to reset it a bad idea and leads to a bad user experience. You don't want people locked out of their website and make them dig in a MySQL database.

4. What's bothering you most about these attacks? Loosing server resources/bandwidth? Or security?

[jorhett]

avryl: what bothers me is how trivial it is to attack the sites. the authentication mechanism is one of the most expensive queries, so 10k hits in a minute and your wordpress install is dead without even breaking in successfully. Hey, let's put our worst foot forward and then make it impossible to hide... genius work there.

It's a trivial fix for WP to implement. They have no actual fundamental reason to not allow the change, except that the botnet is theirs and it is their profit mechanism.

knutsp: dude, you're babbling. Wordpress should not try to make attacks harder, it should make them less successful? Uh huh. Seriously, I am asking you to GO AWAY. This is a serious topic, and you are a nonsense kid with no grasp of the issues involved here. You are filling up a serious bug report with your babble and nonsense, and I am asking you to stop.

[iseulde]

jorhett: Please don't talk to people like that, everyone is here to help and make WordPress better. By being aggressive you only make the discussing you value so much worse.

[dd32]

Ok @jorhett, please take a step back and stop attacking active contributors who are simply explaining their understanding of the issue, there's no need for the tone of your messages.

The WordPress Developers have indeed discussed this, and I believe we would all stand by nacins comments above in comment 15.

The simple fact is that most attack mitigation strategies fail for a large number of WordPress users - think of the people who click the Login link in their site footer and that's all they know. While they will work for a directed attack, they will do nothing to protect random small sites from a 100,000 IP botnet like has been seen in the last year.

Plugins and Server configurations can be used to require 2FA (either as a nonce such as Google Authenticator, a URL parameter, or, simply a 2nd password), and server configurations can be used to alter the login and wp-admin locations or only allow them for authenticated users.

We won't be adding the functionality to rename the wp-login.php or wp-admin url's or anything that would hide the login link (and cause a detrimental impact upon the many WordPress users who are novices), but we are open to hardening WordPress in any way that doesn't affect the users.
Unfortunately no-one has come up with a solution that is appropriate for a project such as WordPress which is used in thousands of configurations of servers which we have no control over - and the users often don't either.
WordPress has been under a constant stream of botnet attacks since Day 0, Comment spam is botnets, Authentication attacks are botnets, spam signups are botnets, they are not dumb scripts, they adapt to the changing environment, and have done so for years.

Other CMS's have found ways which they believe can help (login flood timeouts, comment flood protections, etc) however we're still waiting for someone to make a proposal which we believe can work on already-overloaded shared hosts.

[SergeyBiryukov]

Replying to jorhett:

the authentication mechanism is one of the most expensive queries, so 10k hits in a minute and your wordpress install is dead without even breaking in successfully.

I'd argue that an authentication request is less expensive than a 404 error page on most sites (3 simple queries vs. 25 or more potentially complex ones, depending on the theme).

[jorhett]

And again we are arguing about things that nobody said.

Nobody has ever once said that we should change the login url for sites who didn't expect their URL to be changed. To have both of you jumping up saying this "unexpected" change would break sites... total nonsense.

And how exactly would changing the admin URL *NOT* work for sites to protect them from botnets? You're making this claim but you have no justification for it. If the botnet does not know where the login page is, it cannot succeed in breaking in. How exactly would a 100k or even 1m botnet discover this information remotely? We are not discussing DDoS, we are discussing breakins.

Finally, I find it deeply interesting that while I promote specific technical solutions, you stand up for knutsp - who spews nonsense and personal insults. Why exactly do you prefer personal attacks in your forum, and dislike discussing technical solutions?

Can we please discuss actual technical solutions? I grow very weary of people with no experience fighting botnets making statements with no technical justification that fly in the face of all facts.

[jorhett]

Replying to SergeyBiryukov:

I'd argue that an authentication request is less expensive than a 404 error page on most sites (3 simple queries vs. 25 or more potentially complex ones, depending on the theme).

Is anyone here able to make a technical argument? Or must you all resort to false dilemmas due to the lack of any other way to argue?

1. It would be trivial to replace the current attack points with very low cost responses.

2. I'd be deeply interested in seeing this reality SergeyBiryukov lives in, where an uncached authentication request is less expensive than an answer from cache. Do please do some testing before you make such a claim as this.

FWIW: I will hereby take the "wontfix" action which you have supplied, and the contents of this thread, and turn it over to the lawyers who requested that reasonable efforts be taken to engage with the authors of the botnet host providers. You have clearly delineated that:

1. No technical solution, only false dilemmas, will be evaluated.

2. You have no interest in stopping this botnet.

It has been growing for years, and this issue in particular has been open for nine months, and there hasn't been a single considered, thoughtful response on the topic. I believe you have set the stage quite well for liability to be applied to you.

[jorhett]

Total review of false dilemmas:

mark-k lives in a world where computers can't store information, only people. And people can't read the screen either, so a changed login link is a "password". mark also lives in a world where parsing for a login link in free-form text is just as easy as parsing for a captcha which is presented in exactly the same html in every site. Against all evidence to the contrary. (note that this is exactly the same problem Wordpress has. Make it always the same, you make it easy to attack)

nacin: spins a whole lot of technical sounding answers which cancel each other out

1. Says there are better ways to stop a botnet, but has done nothing, flat zero in 9 months and 4 releases to slow the botnet down.

2. He claims it will break applications (false dilemma again) with no understanding of the irony that the only working solution to slow the botnet down is to put HTTP AUTH in front of the login pages, which has broken applications.

3. He suggests there are drawbacks to moving wp-admin without ever once documenting that list, as every suggestion he has made so far is trivially false dilemma.

4. He says there will be REST, and it will have a single endpoint as well because that's impossible to change too -- denying all reality.

5. And yet again, no sense of irony, he accuses me of not addressing the problem by using two-factor authentication without acknowledging that no application currently supports any two-factor authentication, the same basis for his not solving the problem.

knutsp demonstrates that he knows nothing about botnets, and gives them AI-level human intelligence without any proof of such. Then cries when the false dilemmas he lays claim to are pointed out.

dd32 lays down even more false dilemmas with assumptions that any solution couldn't possibly be user friendly, and tries to equalize botnets created from hacked wordpress sites to comment spam. Further he claims there are no solutions, when this problem has been solved completely and fully in every CMS except Wordpress. Which is why only Wordpress has their own botnet.

SergeyBiryukov claims that it's impossible to make the current attack points low impact, and also claims that caching mechanisms don't work and thus security should never be improved.

Helen just closes it without a word, because it's not even worth thinking about.

SUMMARY:

In total we have a few thousand words and yet not a single one of you has even acknowledged the problem. You dismiss, you create false dilemmas to delude yourself with, and you send personal insults aimed at someone looking for an actual technical solution. Someone who has both the experience and the skills to help you develop a workable solution, but hey that's not interesting to you.

Given the nature of the responses I'm starting to take seriously the idea that wordpress's botnet is deliberately of your own making, given your complete and absolute resistance to any solution which would stop it.

[wonderboymusic]

jorhett:
​http://en.wikipedia.org/wiki/Troll_(Internet)
​http://www.urbandictionary.com/define.php?term=troll
​http://www.urbandictionary.com/define.php?term=trolling

[jorhett]

Core Committers are unable to do anything more than defend using false dilemmas, then insult and attack?

I think people who are under attack by your botnet would disagree that asking that solutions be considered is "trolling".

[TobiasBg]

jorhett, I appreciate your efforts of trying to make the internet a safer place, and I acknowledge your experience with botnets. I even agree that moving/changing the wp-login URL to something secret can help a site to reduce botnet attacks, if it's done right.
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. 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.

Due to those mentioned drawbacks, this approach simply is not suitable for general inclusion into the WordPress core.
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.

[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 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.

[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.

[jorhett]

I don't have time to respond in length, but I think you're missing some basic understandings here.

False Dilemma is not an attack or an insult, it's a rhetorical strategy which has been repeatedly employed here.

For insults, you need to look at "silly", "stupid", "troll" -- these are personal, ad hominem attacks that have been thrown at me. I have stayed on topic, with one exception to point out that someone insulting me didn't have the experience to be a judge of me.

So don't try to lay this at my feet. I think you need to start taking aim at the people who are actually launching ad hominem personal attacks, which has not been me.

Second, nobody is talking about bots commenting on sites. I'm talking about bots which compromise Wordpress sites and then are used for large-scale attacks on other sites. Of course they also break into more sites, but their main goal is to be sold to the highest bidder for large-scale DDoS. This is your problem, and if this isn't your own botnet then why in god's green earth aren't you interested in seeing it killed off?

Finally, your statements that my suggestions would keep users out have no merit and no basis. I'm talking about sites and themes which have clear links to login. That's what users use. The only person who says there would be no link is you -- which is your return to yet another false dilemma. You take away parts of the proposal and then say it won't work. You didn't delineate any actual problems with it, you just claimed it didn't exist. It's fine for rhetorical argument-- if you don't care to be fair and you're not looking for a reasonable discussion. It's not useful if finding real solutions is an actual goal.

This is a very serious topic for me. Must I beg for you to step down from your rhetorical argument space and just dream of considering a real solution?

[mordauk]

@jorhett the best thing to do is just start writing a patch to make the changes you are proposing to fix the problem. While there's no guarantee a patch can be accepted, a patch with proof of implementation will be 1000x better than an argument over what is proposed and what is not proposed going on for another x number of replies.

[JohnPBloch]

For the love of all that's holy, it's "false dichotomy". A dilemma is a situation in which none of the available options is appealing. A dichotomy is a complete disjunction into two completely mutually exclusive parts which together make up the whole. A false dichotomy is a disjunction that results in two things that either have some overlap or do not account for all possible scenarios.

[jorhett]

mordauk: the core problem is that this isn't my first go-round with WP developers and producing patches that they disagree with, even if you fix a problem they acknowledge and have no other fix for, is a waste of time. This issue was opened because I intended to write a patch to solve this very issue, and found that core library changes were essential. Thus, getting buy-in before wasting valuable hours. As you can see, any effort I would have expended would have been wasted.

JohnPBloch: possibly ;-) I don't care enough to debate that one, although I see points both ways.

I'm going to defer my complete answer to Nacin until tomorrow, allowing probably for more coherence and hopefully setting aside some of today's frustration between now and then.

[TobiasBg]

jorhett:
If you can't or don't want to write a patch at this time, that's totally fine, but please give us something regarding your proposal to work with. You say that we "take away parts of the proposal" when there's no actual proposal on the table, or at least what you have suggested is apparently confusing to the majority of contributors in this ticket, in a way that we are not getting anywhere.
Instead of talking about personal attacks that might or might not have taken place over and over again, let's please just return to the topic. For that, please provide details to your proposal in a way that can serve as a solid foundation of discussion: patch/pseudo-code/diagram/sketch/flow chart/algorithm/example/whatever. The current, rather abstract, ticket description won't lead us anywhere, I'm afraid. Neither you nor we want that.

[jorhett]

is there some way of removing this history so I can avoid being pulled into legal action against Wordpress for their inaction against the half dozen botnets of p0wned wordpress sites?