Re: [http-state] Cookie login security inconsistency

"Shelby Moore" <shelby@coolpage.com> Sun, 29 August 2010 00:34 UTC

Return-Path: <shelby@coolpage.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082FC3A63EC for <http-state@core3.amsl.com>; Sat, 28 Aug 2010 17:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level:
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hy0pn8HqYp9 for <http-state@core3.amsl.com>; Sat, 28 Aug 2010 17:34:05 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id 3B0613A63C9 for <http-state@ietf.org>; Sat, 28 Aug 2010 17:34:05 -0700 (PDT)
Received: (qmail 25143 invoked by uid 65534); 29 Aug 2010 00:34:36 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Sat, 28 Aug 2010 20:34:36 -0400
Message-ID: <49dbd31c630ba669698b7e291588d430.squirrel@sm.webmail.pair.com>
In-Reply-To: <291b4e46d2fb81766347c8076858dae5.squirrel@sm.webmail.pair.com>
References: <23e5b79de37d3b7ccfa8f85f6a5de360.squirrel@sm.webmail.pair.com> <011201cb46e4$09527dc0$1bf77940$@packetizer.com> <291b4e46d2fb81766347c8076858dae5.squirrel@sm.webmail.pair.com>
Date: Sat, 28 Aug 2010 20:34:36 -0400
From: "Shelby Moore" <shelby@coolpage.com>
To: shelby@coolpage.com
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: 'Rich Bowen' <rbowen@rcbowen.com>, 'Ben Laurie' <ben@links.org>, http-state@ietf.org
Subject: Re: [http-state] Cookie login security inconsistency
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Aug 2010 00:34:07 -0000

Correcting numerous typos and adding more points...

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


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


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


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


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


"That would be a perfect..."


> 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


"nonce OR a session persistant value"


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