[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