[wp-trac] [WordPress Trac] #25446: Return HTTP status code 401 upon failed login

[WordPress Trac]

#25446: Return HTTP status code 401 upon failed login
-------------------------+------------------------------
 Reporter:  raoulbhatia  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------
Changes (by RavanH):

 * version:  3.6 =>


Comment:

 Landed on this ticket looking for hooks to design a Fail2Ban access log
 filter to block brute-force login attempts. One approach is described by
 Konstantin Kovshenin on http://kovshenin.com/2014/fail2ban-wordpress-
 nginx/ where he needs a response header other than 200 to reliable
 recognize brute-force attempts. He suggests a 403 response but I agree
 with others in this ticket thread that it is not really valid as header
 for the wp-login.php page. Not even after a failed authentication, simply
 because the request is for the login page which IS accessible and thus
 SHOULD respond with a 200 status header.

 So the underlying issue here is in my view the fact that WordPress uses a
 separate login form/page URL. This makes any of the few likely response
 header candidates -- 401 and 403 -- unsuitable.

 This is what happens currently:

 Trying to access the Dashboard (/wp-admin/) when not authenticated, the
 request is met with a 302 (temporary redirect) forwarding the user the the
 login form (/wp-login.php) which in turn responds with a 200 OK header.
 After submitting the form with incorrect login data, the form comes up
 again with a 200 OK response. After submitting the form with correct login
 data, the request is met with a 302 redirecting back to the Dashboard
 which now responds with a 200 OK, obviously.

 This is all according to logic and (in my view) there are no other
 suitable responses in this scenario. And thus, it does not leave much room
 for recognizable access log patterns to be used by security mod filters.

 But...

 What if the whole WP authentication flow was changed? For example like
 this:

 Trying to access the Dashboard (/wp-admin/) when not authenticated, the
 request is met with a 401 response and shows a login form instead of the
 Dashboard. Now after submitting that form with incorrect login data, the
 request is again met with a 401 response (after an X number of failed
 logins this might be turned into a 403 by a plugin like Limit Login
 Attempts) presenting the form again. After submitting with correct login
 data, the request is met with a 200 OK and now shows the Dashboard.

 In this scenario, there are no redirects and the request URL does not
 change. Less confusing and allows different response headers according to
 different visitor credentials like auth cookies, session or POST data. And
 now there would be recognizable patterns in the access log for sec filters
 :)

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