Forum Moderators: phranque
But what security risks does that pose once he's logged in? Could a hacker guess a session cookie, and use it to gain access to his account? Or even snoop the guy's connection?
What are likely ways a hacker could attack this? Are there any accepted ways of preventing this?
So far all I can do is build the user's IP into the session ID and check it's coming from his machine each time, but I thought of using a second cookie - and MD5 of the users email. No way it could be guessed, if a hacker was snooping the connection he wouldn't be able to obtain the email address, but then wouldn't need to if he had the cookie.
Thoughts and suggestions on this?
As you suggested, you could keep track of the user's IP in his session and make sure it's the same each time (though there are legitimate reasons for an IP change, they're relatively rare).
Another method I use is to keep track of the user agent. Granted, this can be spoofed, and isn't necessarily even unique--but it adds another layer of security--and the more layers the better. There are likewise legitimate reasons for this to change, such as a browser version upgrade, but they're rare and generally accompanied by a browser reboot anyway.
Adding another cookie won't do too much for you--if the hacker can steal one cookie, he can steal two just as easily.
Guessing a session cookie is next to impossible. Theoretically, on an extremely heavily-used site, it would be possible--but targeting a specific user would be all but impossible.
A generally accepted practice is to use an ID that's variable in length, contains numbers, letters (upper and lowercase), and (possibly) special characters, and is at an absolute minimum 12 characters in length. Base 64 encoding can provide you with a good ID, given that you encode a unique value. Alternately, you could do some research into GUIDs--they're all but impossible to guess, though challenging to generate properly without a good library.
I think I'll make a little tweak based on what you suggested about using different characters. Currently I'm only using hex - the ID is based on time, IP, PID and a couple of randoms so I think is 14 hex long (28 chars).
But I could MD5 base64 it and store the IP and UA on the backend. Storing the UA would be more secure.
I realise as you said the IP and UA could change, but in these days of broadband it's unlikely, and if the user has to log in again once in a blue moon I don't think they'll be bothered.
Thanks again for the advice!
As you suggested, you could keep track of the user's IP in his session and make sure it's the same each time (though there are legitimate reasons for an IP change, they're relatively rare).
I could be wrong, but I'm pretty sure AOL users have a new IP address for each request (or something like that).
Not sure about the AOL users, but a quick Google search turned up an article indicating that users on AOL dialup do indeed get a new IP for every HTTP request.
A possible way around minor IP changes such as are likely in this scenario would be to only save the first 3 parts of the IP--for instance, in the IP 10.52.36.153 you would save and validate only the 10.52.36 part. Most of the time, when you're assigned a new IP by your ISP only the fourth part will change.
Various sources on the search AOL users can have even more than this changed in the IP--if so, in my opinion the correct response would be "TOO BAD". If these people are that paranoid about security, they're going to end up paying for it--there's no real way around that technical limit.
Thank god I'm not trying to do this 10 years ago, or that might have been a problem! For now I'm happy to exile what should be a pretty small minority of AOL users. Now recent is this information? AOL must realise that IP changing like this will screw up any number of internet apps?
