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

WordPress Trac noreply at wordpress.org
Tue Apr 1 16:54:39 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):

 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 junk:

 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.

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


More information about the wp-trac mailing list