[wp-hackers] Wordpress Cookie Authentication Vulnerability

Thu Nov 22 00:07:11 GMT 2007

Manually picking and having to change a salt often is major pain in the ass
and something the average user won't do.

Better to have it be automated if you ask me.

On 11/21/07, Stephane Daury <wordpress at tekartist.org> wrote:
>
>
> 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
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

-- 
Viper007Bond | http://www.viper007bond.com/