Chad Day wrote: >What I'm looking to do is when a user logs in, I start up the session.. I >then have the registered session var to verify they are authenticated as >they move throughout the site. > >Now, when they close the browser and come back, I want them to still be >authenticated. Obviously, I have to set a cookie. But what do I set? Do I >set just their user ID? The MD5 of their password? What's the most secure >way, that's not easily spoofed? I don't know that much about cookies, but >if I just use a user ID, couldn't someone just change that ID value and >'become' another user? >
Chad, It sounds like you already have a good idea about the insecurity of the method you mentioned. For the most part, trust your instincts, especially when something seems insecure. :-) You just need to try to come up with a method that is difficult to break. Use your creativity, and for each method you can think of, consider what steps must be taken to break the security of that method. There is always a way, but "changing the user ID" isn't very difficult to achieve. The cookie is a good idea, but the value of the cookie is what you need to think about. If its value is, as you mentioned, a user ID, someone could try to guess another valid user ID to impersonate another user. Remember that the cookie is data coming from the client that should not be trusted at all. Take the same precautions against client data as you would candy from a stranger; it doesn't mean it's necessarily bad candy, but you need to create some methods to give yourself pretty good assurance that it's not poisoned, etc. You want to inspect it. In your case, you want to create some methods of assuring, to a reasonable extent, that the cookie is coming from the same client as before. With each connection, there are several things you can check, and you can decide whether its more appropriate to store the data you want to check on the client or on the server. For example, if you were to store the IP address in the cookie also, then someone would have to be coming from the same IP address as before (it would seem). Of course, an observant attacker would change the value of this cookie to their own IP to see if that helped them bypass this check, which it would. What if, instead, you stored the IP address on the server in a database associated with the unique ID? Then you can at least be fairly assured that this value cannot be changed. Another option for you might be to encrypt the IP address and keep it in the cookie. This way, if someone else tried to use the same cookie, their IP address would have to appear to be the same (which of course would happen if it's the same computer). Other information you can get from the client includes the browser type, date, etc. The more things you check, and the more difficult you make it for the client to change this data (otherwise your checks aren't very useful), the more difficult you make impersonation. Just make sure to also cater to your legitimate users, which hopefully there will be more of. :-) If your users connect through a large LAN with multiple proxies, their IP address may fluctuate. Dialup users may have fluctuating IPs as well. If you require someone who fails your checks to only provide their password to continue, then the hassle you give your legitimate users is very minimal, and they might appreciate knowing you're looking out for the safety of their data. These are just some ideas. You're ultimately the best person to decide what security model is best for your needs. Like I said, try to be creative and trust your instincts. A good procedure might be to design what you think is a sufficiently strong and useful security model for your needs and ask the list to come up with hypothetical methods that could be used to break it. If the attacks seem very easy to accomplish, you might need to rethink your methods. Anyway, my point is that you want to educate yourself enough that *you* design the security of your site. Trusting others for your security is no better than trusting candy from strangers. :-) Happy hacking. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
