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

"Roy T. Fielding" <> Fri, 20 February 2015 00:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0648A1A1A7E; Thu, 19 Feb 2015 16:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e0AwuybIhRF4; Thu, 19 Feb 2015 16:10:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 61B6B1A1A78; Thu, 19 Feb 2015 16:10:23 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 2512F77805B; Thu, 19 Feb 2015 16:10:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=gpkLeCxJC0LT7S9WBv1RU1YjrNE=; b=npG4o/oH1y1bw82ICnlEFRqYUwTV dceqvT09RY5CXiYgRJf1OoGJlCAYXSExkaSaH3mfTL6nfbYQLdlDtzOY6iwoxCNw gUslse4WZIru4WgUkX23urvRK2Wak1fOyMVcThs6+IRkbkx9wJgXEqOHW8vQSrRr VQkKEIW/kWbWozI=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id E6FBA778057; Thu, 19 Feb 2015 16:10:22 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Thu, 19 Feb 2015 16:10:22 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Daniel Kahn Gillmor <>
X-Mailer: Apple Mail (2.1283)
Archived-At: <>
Cc: Julian Reschke <>, "" <>,,,
Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Feb 2015 00:10:25 -0000

On Feb 19, 2015, at 3:39 PM, Daniel Kahn Gillmor wrote:
> 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:
> 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.

Right, these files are typically for storing simple barriers -- like
the shared codes you might give out to a family for a picture album.
Good enough to block spiders, but not intended to be secure, and generally
admin-defined rather than user-chosen.  Apache also supports a variety of
hash algorithms for backwards compatibility with previously stored accounts.

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

Yes, what I've seen is typically implemented as a temporary lock-out
on the order of minutes -- long enough to prevent iterative attack
techniques, but short enough that a user wouldn't mind.  It is also
sometimes combined with an alert to the user.  How to implement it
correctly depends on the overall web server architecture, such as
whether the block is only per-server or covers an entire domain.

I don't think we need to describe specifically how to implement it.

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

Fine with me,