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. :-)
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php