justin randell <[email protected]> writes:
> 2009/12/19 Peter Rundle <[email protected]>:
>
>>> Personally I would try to stop using the sessions, and store the client
>>> data in the cookie (assuming its not too heavy) your servers are then just
>>> a pool of state machines. You can yank any at any time with no loss of
>>> service (assuming you take it out of the load balancer first)
>>
>> Yes I agree, I think this is the best solution as the application has so
>> many queries to do on the database in any case before it presents any pages
>> I hardly think that the minimal data stored in the session is worth any
>> speed saving. Then it doesn't matter which server you hit for the "next
>> query".
>
> there are trade-offs here as well - remember that cookie data goes back and
> forth with each request, so this gets painful very quickly. personally, i
> think its best to look at this case by case and use a mixture of cookies and
> session data.
*nod*
> also, you'll likely want to encrypt the cookies if you want to put lots of
> user-data within them.
...and, for the love of everything holy, please, please, *PLEASE* don't write
the encryption stack yourself. This stuff is *HARD*, and unless you are an
expert you can get it wrong.
Obviously, the worthwhile effort to protect your services depends entirely on
the motivation of the attacker, but still...
Why? Because cryptography is pretty hard, but implementing a good
crypto-system that doesn't leak data, allow attackers to change fairly
arbitrary bits, to run tests against your system to recover the secret key, or
determine exactly what to change ... that stuff is hard for experts.
So, if you are going to go down the path of encrypted cookies, don't just grab
the encryption primitives in your language and go to work: get something built
by an expert.[1]
Daniel
Crypto is really, really hard. Lets go shopping ... for an existing solution.
Footnotes:
[1] Which, sadly, doesn't mean you can trust stuff found on the web. :(
All too often that is, for example, prone to using ECB mode, or
vulnerable to attacker-controlled bit-flipping, or other weaknesses.
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
