Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 19 February 2015 23:39 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0991E1A1A48; Thu, 19 Feb 2015 15:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac8m2M3CzNgo; Thu, 19 Feb 2015 15:39:38 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB631A1A45; Thu, 19 Feb 2015 15:39:38 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 1D3B8F984; Thu, 19 Feb 2015 18:39:33 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 04616202F4; Thu, 19 Feb 2015 18:39:31 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Roy T. Fielding" <fielding@gbiv.com>, Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com>
References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de> <9A93C4F9-C14E-410E-81B7-E36E05270FD2@gbiv.com>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Thu, 19 Feb 2015 18:39:30 -0500
Message-ID: <877fvda2tp.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/3Kwhesg1nGkMiOuKXfjyOIDm7QI>
Cc: "http-auth@ietf.org" <http-auth@ietf.org>, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 23:39:41 -0000

On Thu 2015-02-19 18:06:42 -0500, Roy T. Fielding wrote:

> I don't think we use any matching schemes within Apache that do partial
> comparison during mid-algorithm -- IIRC, we recreate the hash based on the
> complete input and then use a string function to compare the result to the
> stored password.  Of course, others could extend Apache to do more.

fwiw, apache on windows and netware apparently does support plaintext
password files:

  https://httpd.apache.org/docs/2.4/misc/password_encryptions.html

it seems likely that this is just strcmp() or the equivalent though i
haven't looked.

I'm not calling out Apache on this, fwiw -- i think Apache httpd is
usually doing the right thing here, and has clearly indicated that this
is insecure.

> A more reasonable thing to say is that any authentication system that
> allows a client to perform more than three failed authentication attempts
> on a single connection, or more than ten on a single account over multiple
> connections, is likely to be vulnerable to password guessing attacks.
> Timing attacks then become completely irrelevant.

This is an interesting suggestion, and should be useful against more
than just timing attacks.  How should that filter be applied?  It seems
like it could create some sort of denial of service attack vector if
it's not done judiciously (e.g. Alice tries to lock out Bob by faking
bad logins from Bob).

>>>>> And sorry, one more question arises for me on re-read. i'm not sure i
>>>>> understand what this means:
>>>>> 
>>>>>     Server implementers SHOULD guard against the possibility of this sort
>>>>>     of counterfeiting by gateways or CGI scripts.  In particular it is
>>>>>     very dangerous for a server to simply turn over a connection to a
>>>>>     gateway.  That gateway can then use the persistent connection
>>>>>     mechanism to engage in multiple transactions with the client while
>>>>>     impersonating the original server in a way that is not detectable by
>>>>>     the client.
>>>>> 
>>>>> How should the server guard against this attack?  what sort does it mean
>>>>> to "turn over a connection to a gateway"?  does "gateway" mean
>>>>> "transparent HTTP proxy" or does it refer to something else?  Sorry if
>>>>> this is elementary stuff, but the term "gateway" only appears in this
>>>>> paragraph.
>>>> 
>>>> That text is present in RFC 2617; I don't understand it completely either.
>
> This is about web server internals.  Back in the early days, when HTTP was
> limited to one request per connection, there was a thing called NPH scripts
> that would allow a script to directly respond to the client instead of their
> response being framed by the server; a trivial implementation could hand
> off the file descriptor to the script and exit.  However, that kind of
> implementation became a potential security hole when persistent connections
> were introduced, since the script could redirect the client to a
> protected space within the same origin (controlled by someone else)
> and receive the redirected request within the script input, bypassing the
> web server's normal request-target hierarchy and collecting the credentials.
> The solution is to never delegate message framing.

Thanks for this explanation, it makes much more sense to me with the
context, and the key takeaway (about delegation of message framing)
seems like it's likely to be still relevant.  Can we incorporate some of
this in the draft somehow?

     --dkg