Forum Moderators: open
Many versions of Internet Explorer leak cookies across domains. If you are using IE and you want to see if your IE leaks cookies, then click on the site in my profile, and then click on the little guy in the lower left corner.
If you are vulnerable to this IE bug, you will see your WebmasterWorld cookie read by me, from a non-WebmasterWorld domain. This means your identity could be hijacked, or the cookie changed. This demo merely displays it in a JavaScript alert box, but it could have been quietly sent to the offending server by way of a one-pixel transparent GIF cgi with a query string attached, or by using a JavaScript "submit" of a form with hidden variables.
A patch has been available since December that reportedly cures this (I haven't tried it):
[microsoft.com...]
On the server side, the easiest solution is to use crypt(), which is available in C and Perl.
Hashed or encrypted cookies offer zero increased security.
Not quite zero. While putting the encrypted password into your cookie will allow you to hijack someone's identity, it's still not quite zero.
1) Most people use one, or a few, passwords across all the various sites they frequent that require passwords. Therefore, knowing someone's actual password is much more useful than knowing only the encrypted form of the password. WebmasterWorld's encryption of the password would probably not be the same of some other site's encryption of that same password. Even crypt() allows you to seed it various ways.
2) Cookie leaks can be triggered by HTML-enabled email that executes JavaScript. Outlook Express works well for this. I don't know about the latest versions, but as of a couple years ago, you only had to see the message in the preview pane and the foul deed was already done. Selected cookies in your IE cookie directory were already on their way to some hacker's server, and you wouldn't even know about it.
3) If a cracker has the encrypted password, he can drop it into a cookie and pretend to be that person, but he can't respond if he's prompted for the password. Therefore, the encrypted cookie system allows for the possibility of prompting for the same password as a check of the user's identity. The encrypted system is scalable -- for more important things (like changing your user profile, and/or changing your password) you can prompt directly instead of relying on the cookie.
The way WebmasterWorld is now, a stolen identity claim may have to back track on IP numbers to establish which one is the imposter, if two parties claim to be the same user with the same password. But if the imposter only has the encrypted version of the password, then he would be unable to provide the original, raw password (assuming that this original password is not displayed anywhere -- not in cookies and not in the profile).
The CPU overhead isn't that great. If encrypted password is in the cookie, then this is the form that's used for matching to the user. The only time the crunching is required is when the user enters the raw password. In fact, for a low-security system such as WebmasterWorld, you might even choose to keep a lookup table in a restricted directory so that crypt() only gets called if the lookup fails. Each lookup adds to the table. But I don't think crypt() is all that CPU-intensive for a system that uses 10-year cookies.
An additional advantage to the lookup table is that you can do a reverse lookup and find out the user's original password, in case he forgot it. But all such conveniences come at the cost of security. The trick is to arrive at a reasonable balance.
