Re: session data vs cookie data

Erik Price wrote:

I have read elsewhere that depending on Cookie data for site authentication is false economy, because Cookie data can be spoofed. I'm designing a login that auto-fills a person's name into a field for authentication (based on their $user_id, which is stored in the cookie), then they enter a password below that name and the fields are checked against data stored in MySQL. Standard authentication system. But from that point onward, I'd like to use a session variable that establishes the user's legitimacy as having logged in, using the cookie to store the SESSID. Barring the user spoofing the SESSID in the cookie, could someone easily fake legitimacy?

No. Can it be done? Yes. "Easily"? No. The default sessid is 32 characters of 36 (a-z0-9). Maybe it's even upper and lowercase, meaning 62 (a-zA-Z0-9). That's 32 ^ 36 combinations. Or is it 36 ^ 32 combinations? Either way, it's a big number of possible session IDs to try to hack at. I remember back in the day when a shop I was at first started using ASP, they were all geeked about some GUID maker that would *guarantee* unique IDs - it would supposedly never generate the same ID twice, ever. I argued with them about that, in that, unless the string it returns can be infinite (it can't, due to memory constraints), there's always a SLIGHT chance of getting the same GUID repeated at some point. For some reason, they didn't believe me. The chances are slight that someone could change a cookie and fake a different session ID. Chances of getting a 'live' one? Very slim, ime.

I would think not, since the session data ("$logged_in = 1" or something similar) is not stored in the cookie but rather on the server. But I just want to confirm. I should mention that I have register_globals = off in php.ini (4.1.0 on Linux).

Michael Kimsal http://www.tapinternet.com/php PHP Training Courses 734-480-9961