Subject: [http-state] Cookie login security inconsistency

From: "Shelby Moore" <[email-masked]>
Date: Wed, 25 Aug 2010 13:04:11 -0400

Some of you know me already from the Hybi WG (WebSockets), so no need to
introduce myself.

Please introduce to the record here, one specific inconsistency from prior
cookies standard for best practices:

https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c26

Also I would like to introduce the entire linked page above to the record
of input to this WG. I notice that Mozilla appears to agree with me on the
solution or way to proceed:

https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c47

I am happy to see some people are working on the problem of http-state and
I hope with an intent of closing the security holes.

Good luck with this.  I wish you all the best.

============
Please note I am not joining this WG and will be unsubscribed after this
post. Please remove my email address from any replies to this mailing
list. If I have something else important to contribute, I will come back
in the future.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 28 Aug 2010 15:05:46 -0400

Shelby,

Sorry for jumping into this so late.  I've been rather busy with other
things.

I read through the material posted.  In general, I do agree that cookies, as
they are defined today, are horrible as a means for managing session state.
Not only can they be snatched off the wire, they *have been* snatched off
the wire and our of proxy caches and elsewhere.  While some issues with
cookies are due to programming bugs, some are wide open security holes.

A colleague and I produced this initial draft as an alternative to the
traditional cookie approach to try to secure session state:
http://tools.ietf.org/html/draft-salgueiro-secure-state-management

This was just our "straw man" proposal, but we think it is one worth
considering.  Ideally, the server would assign an encryption key via HTTPS.
This would be combined with a nonce produced at the client when the session
information is encrypted.  This would result in changing encrypted data and
the nonce value is monotonically increasing so the server can avoid replay
attacks.

It might not be a perfect solution to the problem, but it's a start at
something. 

In any case, we don't really care *how* we solve the problem, but we do
believe it needs to be solved.  Also important, we need a solution that can
be used with HTTP, not just HTTPS.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shelby Moore
> Sent: Wednesday, August 25, 2010 1:04 PM
> To: [email-masked]
> Subject: [http-state] Cookie login security inconsistency
> 
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

---

From: "Shelby Moore" <[email-masked]>
Date: Sat, 28 Aug 2010 20:12:45 -0400

Hi Paul,

> Sorry for jumping into this so late.  I've been rather busy with other

It is a chore to keep up with the various places that standards are
promulgated.

Thanks making the effort.

I am late to reply because I have been swamped also.

> the wire and our of proxy caches and elsewhere.

Thanks for confirming that it is not only a theoretical problem.

>  While some issues with

Agreed.  Closing holes is real security.

I went one step further than your point, to assert that making artifical
limitations on programming APIs would actually DECREASE security, and this
is due to Coase's Theorem (nature will route around any artificial barrier
that increases opportunity costs):

http://www.ietf.org/mail-archive/web/http-state/current/msg00932.html

I forgot to mention Coase's Theorem in the above post, so thanks for
raising the issue again.

> http://tools.ietf.org/html/draft-salgueiro-secure-state-management

I did not yet have time to read that.  I will comment on your summary below.

> the nonce value is monotonically increasing so the server can avoid replay

Wow, I really like the idea of the encryption key for encrypting the
cookies stored on the client disk.  That way the user of the client
browser does not have to establish a master password.  And each site's
cookies are encrypted on the client's disk with a different encryption
key. What would be a perfect solution afaics now. Is that what you mean?

As for the nonce concept for session keys:

1) I think we keep that concept orthogonal to the encryption of cookies on
the client disk.  It could be in the same draft, but a different section.

2) Unfortunately I don't think that nonce against reply attack is
security. Because if intruder gets the nonce before it has been used, that
is still a hole. I believe in closing holes instead. It we properly guard
the session id, it won't matter if it is a nonce of a session persistent
value. Nonces are good idea for other reasons too (e.g. recognizing a
stale request), and I think the application should be free to use them,
but I don't think they should be mandated for security reasons. I for one
don't use them in my design and wouldn't want to be forced to use them.

> be used with HTTP, not just HTTPS.

Yes I would also like solutions for HTTP too.  I am prioritizing HTTPS, so
at least those who think they are secure, will actually be.  I am tired of
the lie of the lock icon at the bottom of the browser.

---

From: "Shelby Moore" <[email-masked]>
Date: Sat, 28 Aug 2010 20:34:36 -0400

Correcting numerous typos and adding more points...

> I forgot to mention Coase's Theorem in the above post, so thanks for

I think there are far too many cases where we chase the shadows, instead
of real holes and solutions. And this is destroying the
freedom/opportunities on the internet in my opinion (will end up with the
big server farm companies being the only ones whitelisted and rest of us
in slavery).

For example, the whole concept of firewalling everything and then
whitelisting the internet.  That isn't security, it is just a way of
letting only the viruses come in and not the useful programs. When
programs have to written with STUN tunneling like a virus, the internet is
fundamentally broken by Almost-Better-Than-Nothing security models. So now
99% of the possible internet connections are unavailable unless one writes
their program like a virus:

http://www.ietf.org/mail-archive/web/hybi/current/msg03549.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03231.html

IPv4 said that NATs should not be doing what they are doing. I don't think
IPv6 will fix the problem, because it is not a problem just of available
of IP addresses, but also of wrong security models.

Instead if we have full disk and OS encryption and protection, then the
firewall model is unnecessary:

https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c41

I can advance that to CSRF attacks too, where I can not find any logic in
categorizing a payload attack as CSRF when it was injected some other way
(the real hole is the injection point), not via violation of Same Origin
policy (SOP). This misunderstanding leads to overzealous SOP that is
unnecessary and also further whitelists and destroys the internet model of
mesh networking:

http://www.ietf.org/mail-archive/web/hybi/current/msg03334.html
https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c14

> browser does not have to establish a master password.

I meant the encryption key comes from the server via HTTPS as you wrote.

>  And each site's

"That would be a perfect..."

> the session id, it won't matter if it is a nonce of a session persistent

"nonce OR a session persistant value"