[cryptography] not a Paypal phish using EV certificate

Krassimir Tzvetanov maillists at krassi.biz
Wed Aug 14 03:11:25 EDT 2013

To: James, just with the scope of large/small cookies.

The problem is that if your cookie is a single number and you have multiple
frontends able to process the request (and you are load balancing) you need
to have those share state in which might not make sense (esp. if you have
geo-distributed LB that allows users to migrate between different data
centers because at that point you need to account for cross data center
latency). So usually people end up putting the state data in the cookie and
then sign it in some way.

Sometimes the large and multiple cookies are a matter of low level of
coordination between teams writing different parts of the app/libraries,
and sometimes it's pure incompetency :)

Regarding multiple domains, one of the reasons is the larger companies
would push the static content to CDN and only keep the core logic on site,
thus accelerating delivery. In addition to that in PP's case they are
moving to the CDN a lot of user provided content so combine that with what
was already said about separating the domain so cookies cannot be stolen.


On Tue, Aug 13, 2013 at 4:38 PM, Seth David Schoen <schoen at eff.org> wrote:

> James A. Donald writes:
> > Although websites often use huge numbers of huge cookies, one can
> > easily optimize one's cookie use.  I can see no reason why anyone
> > would ever need more than a single 96 bit cookie that is a random
> > number.
> They might want to make the content and purpose of the cookie
> transparent to the user, and perhaps even reassure the user that
> the cookie can't easily be used as a unique identifier for the
> user's browser.
> On the flip side, there are also some mechanisms to store
> authenticated, encrypted session state in its entirety on the
> client in order to _avoid_ storing it in a database on the
> server.
> --
> Seth Schoen  <schoen at eff.org>
> Senior Staff Technologist                       https://www.eff.org/
> Electronic Frontier Foundation                  https://www.eff.org/join
> 815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130814/9da60b86/attachment-0001.html>

More information about the cryptography mailing list