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

WordPress Trac wp-trac at lists.automattic.com
Mon Dec 24 06:10:09 GMT 2007


#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):

 Replying to [comment:62 ryan]:
 > New patch uses SECRET_KEY instead of the DB secret if defined.  Should
 we do this, or concat SECRET_KEY with the db secret and provide a separate
 SECRET_SALT define that can be used to replace the db secret?

 I'm think I'm leaning toward the second option. I'm not comfortable
 betting the farm on SECRET_KEY staying secret.  We've gone from any who
 can get read access to the DB being able to generate a cookie to any who
 can read wp-config.php being able to generate a cookie.  HTTP server
 exploits and directory traversals can expose wp-config.php.  Having part
 of the key live in the DB provides a belt to go with our suspenders.
 Granted, someone who can get at wp-config.php will also get DB login
 information, but DB servers shouldn't be accepting connections from
 anywhere.

 So, for the convenience of integrators, SECRET_SALT would be provided to
 override the DB salt.  SECRET_SALT could be defined as a constant
 somewhere or populated with a value from a table shared by the
 applications being integrated.

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


More information about the wp-trac mailing list