Brad Van Sickle <bvansick...@gmail.com> writes:
>>
>>> 3) Being enabled by item 2, add more webservers and balancers
>>> 4) Create a separate database for cookie data (Apache::Session objects)
>>> ??? -- not sure if good idea --
>>
>> I've never seen the need to do that. In fact, I would suggest you
>> drop sessions altogether if you can. If you need any per-session
>> information then put it in a cookie. If you need this information to
>> be tamper-proof then you can create a hash of the cookie's data that
>> you store as part of the cookie. If you can reduce the # of times
>> that each request needs to actually hit the database you'll have big
>> wins.
>>
>>
>
> Can I get you to explain this a little more? I don't see how this
> could be used for truly secure sites because I don't quite understand
> how storing a hash in a plain text cookie would be secure.
The general idea is that you store a cryptographic hash of the cookie
information plus a secret only your app knows. Using | to show string
contatenation, your cookie would be:
YourCookieFields|HASH(YourCookieFields|YourSecret)
An attacker can't create the right hash because they don't know your
secret, and they can't change any fields in the cookie because the
hash would become invalid.
-----Scott.
