Re: maintaining [user] state without a session ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 3:16 PM +0000 3/13/08, Stut wrote:
tedd wrote:
Nice article.

Thanks.

I question the reason why you would want to encrypt the cookie considering that before the user is going to be provided access to sensitive data that you require a password confirmation. The encryption seems to be an unnecessary overkill.

So what if a malicious user uses a cookie to pretend to be a real user IF before they can get access to sensitive data they have to enter a correct password?

Please explain.

Certainly. It's not about them getting access to the data in that cookie, it's got more to do with ensuring the cookie contents remain unchanged.

While it's true that the "remember me" cookie could live with not being encrypted I would then need to validate the data it contains. By encrypting it I know that if it decrypts successfully it's exactly what the site put in it at the end of the last request.

For some sites this would not be an issue but due to some of the ways we use the data in that cookie I decided the cost of encrypting it against the cost of validating it and the risks involved made encryption the better option.

There is another reason... Cookies are sometimes stored in plain text on the users machine. Since that cookie contains an email address and potentially a phone number it's much better to encrypt it and protect our users.

Hope that answers your question.

-Stut

Okay.

Considering that all user data is placed in a database for extraction as needed, then why not put the state of the user's last visit in there as well and save only the session id (or whatever) as a cookie?

Then, when the user returns, you simply check the cookie with what's stored in the dB and continue as before. If the check fails (no session id or it has been altered), then start again.

To do house keeping, simply run a routine at some interval to check the sessions' age and remove those that are older than what's wanted.

Why put anything client-side that might be a security problem?

Cheers,

tedd


--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux