[cgiapp] enciphered-cookie-only sessions

[Ricardo SIGNES]

* Mark Fuller <azfuller at gmail.com> [2008-03-11T10:52:29]
> On Mon, Mar 10, 2008 at 9:54 AM, Ricardo SIGNES
> >  I wouldn't use this for anything like banking or credit cards, but I feel
> >  pretty okay about it for things like a Rubric login.
> 
> The problem (from my perspective) is that if it's encrypted *I* have
> no idea what you're trying to store on *my* computer. Nor what
> encryption method you've chosen (if any at all, it could be base 64
> encoding to obfuscate the data), your diligence in choosing a
> passphrase.

If you don't trust my ability to make security decisions, you shouldn't use
services I provide.  Period.  If I only stored a session key, and then looked
up sessions in Amazon S3, where I stored your credit card number in the clear,
with a password of "rjbs" you would never know.

One must make security decisions based on the reputation of the service
provider, because the implementation details will generally not be exposed.

> >  Probably what I'll do in the (near) future is have an n-day log of secrets,
> >  generated daily.  The cookie will then be like
> >
> >   { generated: yyyymmdd, cookie: ciphertext }
> >
> >  You'll have to crack the secret within n days, which makes it even more
> >  tedious.
> 
> I was thinking more along the lines of a cracked cookie being harmful
> to me, not you. :)

If cookie vulnerability means someone can alter someone else's data, it's bad
for the service provider AND the service consumer.  Am I missing something?

I guess someone could store child porn in encrypted cookies on users'
computers, but... 

What's the specific problem you're objecting to, here?

> This just doesn't seem like a good use of a cookie to me. It could be
> a good use. But, as the person upon whose computer it is being placed
> (which might be a public computer, et al), I can't tell if it's a good
> use because it's encrypted. A lack of transparency into what's being
> placed on (hopefully) my computer doesn't seem like a good thing. It
> may make the operator's processing more efficient and scalable. But,
> I'm old enough to remember people making that argument for storing
> private information as hidden form fields 15 years ago.

...but fifteen years ago, the data was still visible in the clear, so it was
obviously stupid for any use case where the connection was not secure end to
end.  I don't see a serious security vulnerability here, at least for services
that will not be attracting huge amounts of CPU-years of attack per day.

Is your objection just that you don't want me storing anything in your
browser's cookie jar that isn't plaintext or a serial number?

-- 
rjbs