Re: [http-state] Cookie login security inconsistency

["Shelby Moore" <[e-mail]>]

Hi Paul,


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


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.


> 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.


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


>  While some issues with
> cookies are due to programming bugs, some are wide open security holes.


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.


> 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


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


> 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.


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.


>
> 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.


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.

>
> Paul
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On
>> Behalf Of Shelby Moore
>> Sent: Wednesday, August 25, 2010 1:04 PM
>> To: [e-mail]
>> Subject: [http-state] Cookie login security inconsistency
>>
>> 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.
>> _______________________________________________
>> http-state mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/http-state
>
>
>