Again, "It's not perfect, but I don't think anyone has come up with a better way."
It's called session hijacking, and it is a great reason to use SSL. However, there's still the issue of cross-site scripting, which can really only be prevented by smarter coding. Even then there are issues. For example, holes in ie's SSL capabilities (including a current, unpatched vulnerability- well okay it was patched but M$ managed to re-introduce it in more recent patches...), permit undeteted MITM attacks. On Saturday 31 May 2003 05:56 am, Dustin Mitchell wrote: > On Fri, May 30, 2003 at 11:01:26PM -0700, Evan Nemerson wrote: > > Send a session ID to the user in a cookie, then lookup that ID in a > > database on the server. It's extremely difficult to guess random session > > ID's (don't just increment them!), and if you have a session timeout, > > you're pretty much set. > > That's true, and it is what most people do, but if you think about it the > session ID is then functionally equivalent to a crypt'd password for the > duration of your session; that is, either one allows you access to the > site. So if you were worried about folks sniffing an encrypted password and > using it to log in, you should be equally worried about folks sniffing a > session ID and using *it* to log in. > > Dustin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
