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?


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.


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to