[wp-trac] [WordPress Trac] #43576: Do not expose user_login through cookies

[WordPress Trac]

#43576: Do not expose user_login through cookies
------------------------------------+-----------------------------
 Reporter:  marcus.downing          |      Owner:
     Type:  enhancement             |     Status:  new
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Login and Registration  |    Version:  trunk
 Severity:  normal                  |   Keywords:
  Focuses:                          |
------------------------------------+-----------------------------
 An ITHC recently reported that the cookies `wordpress_logged_in` and
 `wordpress_sec` contain the current username. This exposes the possibility
 that user's username can be extracted by a third party that is able to
 read the cookie.

 Of course the cookies themselves should be and are protected in other ways
 (including `HttpOnly` and `Secure`), and an attacker who has managed to
 intercept a session cookie already has the means to log in as you; but if
 the security issues seen in recent years (to all software, not just
 WordPress) have taught us anything it's that if you take security serious
 you need to close all the doors, not just one of them.

 I understand that some may regard this as a non-issue, but since it was
 raised to us during a security review we're obliged to take it seriously.


 === Proposed solution ===

 On user login, a unique value is created and saved in usermeta. This value
 should be different each time you log in, and reveal nothing about the
 user or their ID. The value is sent with the cookie in place of the
 username. Multiple such records can and will coexist, representing the
 user logging in from multiple devices.

 On cookie verification, the value is retrieved from usermeta and used to
 find the user ID.

 This solution has the added benefit that it will be harder for an attacker
 to fake a WordPress login cookie even if they have your database and
 salts, since any session they created would not be in the database. On the
 other hand it has a side effect that losing the current user login entries
 from usermeta (such as by reverting to backup database) would invalidate
 login sessions.

 As a downside it would involve a reasonably high turnover of temporary
 records in the usermeta table; it may be preferable to use transient
 entries in the options table instead.

 An alternative solution would be to reversibly encrypt the username part
 of the cookie, and decrypt it on verification.


 === Affected code ===

 In `wp-includes/pluggable.php`, the functions:
 `wp_generate_auth_cookie($user_id, $expiration, $scheme, $token)`
 `wp_validate_auth_cookie($cookie, $scheme)`.

 Note that the pluggable nature of these functions means I can (and
 probably will) write a plugin to address the issue on my own site.
 However, I believe this change may benefit security for others and should
 therefore be addressed in core.


 === Possibly related ===

 #9577 use user_id rather than user_login in the authentication cookie

 This was discussed in a different context and rejected 9 years ago, but
 the issue isn't the same, and I believe we've all learned more about
 security in the last 9 years.

 In particular, this issue suggested using the user's ID rather than their
 username. This provided little or no security benefit, because there are
 various ways of getting a user's login from their ID. My suggestion above
 instead uses a temporary code that reveals nothing and is hard to fake.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43576>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform