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

WordPress Trac wp-trac at lists.automattic.com
Thu Nov 22 14:14:17 GMT 2007


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

 Otto42:

 > Salting the passwords would be nice to prevent dictionary attacks, and
 using something other than MD5 would be nice as well, but these won't
 solve the problem.

 They won't solve the problem completely but they will help quite
 considerably, so this is not a valid reason for not salting. It's all part
 of a strategy of "defence in depth," which is an approach that security
 experts all strongly recommend.

 You need to have an extremely good reason to reject an additional
 recommended security measure, especially when its impact on usability or
 other functionality is zero.

 However, I'd agree that sessions are the way to go rather than throwing
 around hashes of your user name and password in cookies.

 nbachiyski:

 > one day the rainbow databases may include many md5 strings hashes, or
 even triple hashes, but I think it would suffice for now.

 I wouldn't put it past crackers to come up with one, especially given the
 popularity of WordPress. That's why I'm strongly in favour of salting in
 addition to everything else. Again, it boils down to "defence in depth."

 In short, we need to do '''all''' the following:

  a. salt users' passwords
  b. use a more secure hash algorithm than MD5
  c. use PHP sessions rather than user name and password
  d. give sessions a finite (sliding) expiration time of no more than a few
 hours.

 It would also be a good idea to consider tying sessions to a specific IP
 address or range of IP addresses, although this could cause usability
 problems for AOL users who go through random proxy servers.

 Another thing -- why has this been given a milestone of 2.4? Since it is a
 security issue that is actively being exploited, shouldn't it be
 scheduled, at least partially, for the next security release?

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


More information about the wp-trac mailing list