[wp-trac] Re: [WordPress Trac] #5367: Wordpress cookie authentication vulnerability

[WordPress Trac]

#5367: Wordpress cookie authentication vulnerability
-------------------------------------+--------------------------------------
 Reporter:  sjmurdoch                |        Owner:  westi   
     Type:  defect                   |       Status:  assigned
 Priority:  normal                   |    Milestone:  2.4     
Component:  Security                 |      Version:  2.3.1   
 Severity:  normal                   |   Resolution:          
 Keywords:  security, password, md5  |  
-------------------------------------+--------------------------------------
Comment (by ryan):

 http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf

 That defines the following cookie structure.
 {{{
 user name|expiration time|(data)k|HMAC( user name|expiration
 time|data|session key, k)
 where k=HMAC(user name|expiration time, sk)
 and where sk is a secret key
 }}}

 To fulfill HMAC, we need the hash_hmac() function.  We can fall back to
 the Crypt_HMAC code from PEAR if that is not available.

 (data)k requires two-way encryption.  We have that only if the mcrypt
 module is available.  I don't know how widespread that is among hosts.  I
 think that the data field is optional, however. We don't have any
 additional data we need to put in the cookie.  Losing the data field loses
 the mcrypt requirement.

 Since most WP installs don't run over SSL, we have to drop session key.
 The cookie now looks like this:

 {{{
 user name|expiration time|HMAC( user name|expiration time, k)
 where k=HMAC(user name|expiration time, sk)
 and where sk is a secret key
 }}}


 That looks pretty good, but leaves us with an attacker being able to
 create a cookie if he has access to the secret key in the DB. I think we
 can get around this by having part of the key defined in wp-config.php.
 We currently save a randomly generated secret in the 'secret' field in the
 options table.  wp_salt() uses this for creating nonces.  We can
 supplement this secret by concatenating it with a SECRET_KEY defined in
 wp-config.php. We can provide a default SECRET_KEY, but users will have to
 change this to something unique for it to be effective in preventing an
 intruder who knows the DB secret from creating a cookie.  We don't allow
 viewing wp-config.php   from anywhere in WP, so SECRET_KEY should be safe
 from intruders who can see the DB or who have gained user permissions.  We
 could drop the secret from the DB and use just SECRET_KEY, but this would
 rely on users changing SECRET_KEY.  We can't rely on that, so augmenting
 SECRET_KEY with a randomly generated DB secret is necessary.  Not everyone
 will change the SECRET_KEY, but the option is there for those wanting
 extra protection.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/5367#comment:29>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software