[wp-hackers] Wordpress Cookie Authentication Vulnerability

Wed Nov 21 14:48:07 GMT 2007

re: MD5: MD5 has been cracked, that's why people are now uncomfortable  
with it.
I often use sha1 instead <http://ca.php.net/sha1>.
Technically, there's also been rumours it was cracked (collisions),  
but less so.
http://slashdot.org/article.pl?sid=04/08/17/0030243
http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-cracker/

But hey, we're okay, 'coz we'll have a replacement by 2012. ;-)
http://it.slashdot.org/article.pl?sid=07/11/09/1812242

re: salt: That's why I think a session id is a better idea, because  
they're new every time the user logs in and expire.
wp_user
-> username (text)
-> password (double_md5, as now, for backward compatibility)
-> session_id (md5/sha1, salted)
-> session_date (for expiry calculation)

So on login, the username and md5_pass are checked, as usual.
If successful, a session_id is generated, added to the user's record  
and in the user's cookie.
Then at each page load, you just check for the session_id, and check  
the expiry.
The salt for the session_id is a central value, defined by the site's  
admin in the main options.
The installer just has to generate a first random  value, and suggest  
the admins change it on a regular basis.
This way, the worst case scenario when the salt is updated for  
maintenance or because of exploit concerns, the only thing that  
happens is that the logged in users get logged out.

Now, if you wanna go the next level up, and actually also check the  
validity of the structure of the session key at each page load (some  
do), you define a reproducible generation algorithm (like  
sha1(sitewide_salt + user_ip + username +  
some_other_data_that_won't_change_in_the_session)), then see if what  
you have in the cookie is in the db and is valid.

Stephane

On Nov 21, 2007, at 0:37, Computer Guru wrote:

> Ermm... just to point out: you would add the second SALT column  
> *after*
> you're database has been compromised.
>
> On 11/21/07, Computer Guru <computerguru at neosmart.net> wrote:
>>
>> Unfortunately not.
>>
>> There are libraries available in other languages, but MD5 has been  
>> the
>> "standard" in PHP-based web-apps for too long.
>>
>> I find myself linking, once again, to Jeff Atwood's excellent  
>> article:
>> http://www.codinghorror.com/blog/archives/000953.html
>>
>> This section jumps out at me in the current context:
>> *********
>> *Do not invent your own "clever" password storage scheme*. I know,  
>> you're
>> smart, and you grok this crypto stuff. But through this door lies  
>> madness--
>> and abominations like LMHash <http://en.wikipedia.org/wiki/LM_hash>  
>> that
>> have ongoing, worldwide security ramifications we're still dealing  
>> with
>> today. Take advantage of whatever password storage tools your  
>> framework
>> provides, as they're likely to be a heck of a lot better tested and  
>> more
>> battle-proven than any crazy scheme you and your team can come up  
>> with on
>> your own. Security vulnerabilities, unlike functionality bugs in your
>> application, run deep and silent. They can lay dormant for years.
>> ********
>>
>>
>> At any rate, my REALLY simple answer to the whole "having passwords  
>> in the
>> db means crackers can fake cookies" problem:
>> Add a second SALT column to your database. Make password hashes
>> twice-salted; therefore effectively:
>> 1) Rendering all existing hashes useless
>> 2) Logging out all users
>> 3) Preserving backwards compatibility in that you can use the data  
>> you
>> already have to make the new hash.
>>
>> Only problem is, it probably doesn't work too well for a published  
>> package
>> like WP.... It's fine for company XYZ running their own software,  
>> hosted
>> in-house, w/ real coders available to make the change on demand; it
>> addresses all the problems; and it's easy to use.... but it  
>> definitely won't
>> work when you're distributing the code for others to deploy..........
>>
>>
>> -CG
>>
>> On 11/21/07, Otto <otto at ottodestruct.com> wrote:
>>>
>>> Great! Now that you like the idea, let me shoot it down. :)
>>>
>>> This approach prevents "staying logged in" on multiple computers. I
>>> login from work and home. I leave my cookie on both, and have no
>>> issues. With this approach, I have to login every time, since the  
>>> BRS
>>> keeps changing. Can true session ID's solve this?
>>>
>>> Longer term answer: Why are we building this logic ourselves anyway?
>>> This seems like it should be a solved problem. Is there no PHP  
>>> library
>>> that will do this for us?
>>>
>>> -Otto
>>>
>>>
>>>
>>> On 11/20/07, Bas Bosman <wordpress at nazgul.nu> wrote:
>>>>> Is there any reason in particular WP is using MD5 as opposed to a
>>>>> stronger algorithm?
>>>>
>>>> Yes, because WordPress still supports PHP 4.2, which doesn't really
>>> have
>>>> any good support for a stronger algorithm.
>>>>
>>>> But as mentioned in the Trac ticket. MD5 isn't the issue here. The
>>> issue
>>>> is that we have a guessable cookie, based on read-only database  
>>>> access
>>> or
>>>> non-ssl network sniffing.
>>>>
>>>> I think Otto gave a nice overview of a possible solution. Which can
>>>> optionally be enhanced by linking login cookies to ip-adresses to
>>> further
>>>> minimize the chances of cookie stealing. (Mark the optional,  
>>>> because
>>> it
>>>> can have unwanted side-effects in some network setups)
>>>>
>>>> Regards,
>>>> Bas Bosman (Nazgul)
>>>>
>>>> _______________________________________________
>>>> wp-hackers mailing list
>>>> wp-hackers at lists.automattic.com
>>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>>
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>>
>>
>>
>> --
>> Computer Guru
>> Director,
>> NeoSmart Technologies
>> http://neosmart.net/blog/
>>
>
>
>
> -- 
> Computer Guru
> Director,
> NeoSmart Technologies
> http://neosmart.net/blog/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers