Page 2 of 2

Posted: Sun Apr 11, 2004 9:15 am
by Buddha443556
tim wrote:
LiLpunkSkateR wrote:it's just as much of a risk as saving the password.
how so? your running the value in the cookie against the value in the DB ( least in my example?) I mean, i'll give u the username script I first wrote.

If a user can guess your password n replace the value in the cookie, well it isnt the scripts fault, its the users. everyone chooses abcd or 1234 as their passwords, any brute program can crack that in a second.

i'm just a lil confused on that :?:
I don't want to put words in Punk's mouth, but I think Punk is refering to the risk associated with storing data on the clients computer. Be it a password (and username, they really go together) or a session id, by storing it on the users computer you have to trust them to keep it safe. Trust and risk go together.

How do we mitigate the risk of trusting the user to store this information? If we give them a username/password to store and it is exposed then what are our options? Since the badguy has the username and password we have to change one or both of them. The legitimate user need to be informed of these changes. What if a session id is exposed? Since the badguy has only the session id we can delete it. The legitimate user just logs back in and get a new session id. Using session ids we can at anytime challenge the user for their password. We can't do that if the badguy has it.

We don't store passwords in cookie for the same reason we don't write them down on post-it notes and stick them on the monitor. The session id limit the amount of information we expose by trusting the user thereby limiting our risk.

Posted: Sun Apr 11, 2004 11:27 am
by Ixplodestuff8
One problem with sessions is that if a user doesn't have cookies enabled and the session is stored in the url, then It can be stolen if the user clicks on a link to an external site, the referal would have the session id there.

If you have control over the server you can just turn off the feature that rewrites urls to include the session, or you can build your own session system, but if you can't it'll be much easier to steal a session from a url bar than a cookie.

What I usually do is store the username and password hash in the cookie, but add a random string to the end of the password before md5'ing it so if I change this string all cookies are made invalid. Or to not annoy every user when you change this, you can have a unique random string appended to their password, so you can reset the cookie for an individual.

Posted: Sun Apr 11, 2004 4:43 pm
by Buddha443556
Ixplodestuff8 wrote:One problem with sessions is that if a user doesn't have cookies enabled and the session is stored in the url, then It can be stolen if the user clicks on a link to an external site, the referal would have the session id there.

If you have control over the server you can just turn off the feature that rewrites urls to include the session, or you can build your own session system, but if you can't it'll be much easier to steal a session from a url bar than a cookie.
I've been using my own system since before 4.0. I use it for administrative purposes so forcing the end user to use cookie is easy.
Ixplodestuff8 wrote:What I usually do is store the username and password hash in the cookie, but add a random string to the end of the password before md5'ing it so if I change this string all cookies are made invalid. Or to not annoy every user when you change this, you can have a unique random string appended to their password, so you can reset the cookie for an individual.
I don't store actual passwords. I store an MD5 of the username and password on the server. The cookie is just a random 32 character hexdecimal.

Posted: Sun Apr 11, 2004 8:11 pm
by Ixplodestuff8
Having your own system is another option aswell :P , I think having your own system is the best approach since you can control everything, but the downside is actually making/finding one that works well.