[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:  reopened
 Priority:  normal        |   Milestone:
Component:  Security      |     Version:  3.5.2
 Severity:  critical      |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+-----------------------

Comment (by 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 [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.

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