-- Posted by Mediocre at 8:22 pm on Aug. 15, 2008 So, I just finished coding the login script for an upcoming project. It relies on a session cookie with a value that is (essentially) the user's password, hashed. I'm worried that someone could steal the value of this cookie and then create "poisoned" cookies with that value whenever they want to impersonate their victim. One way to mitigate this would be to salt the password hash with something (like the day's date) that would make the cookie only work for a limited time. How do other coders take care of this? Or is it considered acceptable to use a cookie that could last forever? Salting with the user's IP will not work, because most of my visitors connect via Tor... -- Posted by telomere13 at 8:31 pm on Aug. 15, 2008 You can put the date in, but you need to make sure that it's secure, because if the person can extract the date from the cookie, they can make their own with any date. So I would say, at very least, use a pseudorandom generator seeded with the date, but if you want any reasonable degree of security, look at the code for an open source messageboard software (like PHPBB). (edit)Keeping the password's key, forever, is really no better than storin the password in plain text. -- Posted by Mediocre at 9:13 pm on Aug. 15, 2008 Well, I decided to name the cookie (something to the effect of) Code: "orly_".sha1(CzQTqaxd29TP1zag9AlENL0sMPsaNGiNju2nhoRZ.date('zYF')) I don't see how this could realistically be reversed. -- Posted by telomere13 at 9:17 pm on Aug. 15, 2008 I have no idea what language you're using so that means absolutely nothing to me.   That said, is the date reversible in any way?  As long as the date is reversible and the rest is constant, all you need to do to make a fake cookie is use the current date with the constant part.