--- "Chris W. Parker" <[EMAIL PROTECTED]> wrote: > But seriously, why is it such a bad idea? I'd like to finally figure > this out so I don't keep coming up with them (not that I've ever used > any). ;)
I have a free chapter that explains cookies at the protocol level here: http://shiflett.org/books/http-developers-handbook/chapters/11 The idea of cookies is a very good one, and Netscape deserves credit for the innovation. However, some implementations have been known to have problems. Most notably, Internet Explorer versions 4.0, 5.0, 5.5, and 6.0 all have vulnerabilities that, if not patched, allow anyone to read cookies from any domain. This means that Web developers, such as ourselves, must consider all information in a cookie to be public for the purposes of security assessment. The worst case scenario must be taken into consideration, and when you set a cookie, the worst case is that the contents are compromised. So, getting back to your approach, you store authentication credentials in a cookie, although you mentioned several steps that add obscurity. Even if the data in the cookie cannot possibly reveal the user's authentication credentials, if your session mechanism considers the cookie itself to be an authentication credential, you have already lost. Anyone who can compromise this cookie can impersonate a user on your Web application. A security vulnerability is born. Hope that helps. Chris ===== My Blog http://shiflett.org/ HTTP Developer's Handbook http://httphandbook.org/ RAMP Training Courses http://www.nyphp.org/ramp -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
