[wp-trac] [WordPress Trac] #27052: Known admin user_id ( = 1 ) could lead to security problems and/or unwanted side-effects

[WordPress Trac]

#27052: Known admin user_id ( = 1 ) could lead to security problems and/or unwanted
side-effects
-------------------------------------------------+-------------------------
 Reporter:  ruud@…                               |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Upgrade/Install                      |  Review
 Severity:  normal                               |     Version:  3.8
 Keywords:  has-patch needs-testing 2nd-opinion  |  Resolution:
                                                 |     Focuses:
-------------------------------------------------+-------------------------

Comment (by ruud@…):

 Replying to [comment:3 johnbillion]:
 > If you're writing security enhancements you really need to be a little
 more certain about why you're doing it, and provide much more concrete
 details about the risk and about the enhancement your patch provides.
 >
 > Your description goes on to explain what your patch does but you don't
 explain why. I suspect I know what risk it's trying to address (blind SQL
 injection attacks on known user ID 1) but this isn't explained.

 I agree, fixing problems which do not really exist is totally not worth
 it.
 I don't have any examples to add right now, maybe someone else has them?

 Also: when somehow an attacker has SQL injection 'capabilities' on your
 install than a random admin user_id probably won't help out much because
 via the user_meta table and a 'wp_capabilities' test for any serialized
 administrator object will still get the attacker an admin user_id.

 Another security risk alley is when an attacker can not do SQL injection,
 but can become any user by ID. In that scenario it is too ease to be an
 admin if you can still use ID=1.
 I don't know any examples of this either.

 So if no real security threat can be circumvented by this patch then only
 the 'unwanted side-effects' will be remedied by this patch, like mistakes
 such as:

 {{{
 $current_user = wp_get_current_user();
 if ( $current_user->ID ) {
     // admin related code
 }
 }}}

 But then again that's just stupid really.
 So.. it looked like a nice add-on but in hindsight I'm not sure anymore,
 unless someone can come up with better examples.

 ps:
 While thinking this through I also thought that just choosing a random
 starting point for numbering the users is not really a good thing because
 it still gives an attacker the option to start back-tracking the user ID's
 from subsequent registered users.
 A second randomized AUTO_INCREMENT value after the first user is inserted
 into the database would prevent that.

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