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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 19 February 2015 18:23 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 0DEEB1A0158; Thu, 19 Feb 2015 10:23:08 -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 0XOdUUgPuGh9; Thu, 19 Feb 2015 10:23:04 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4750D1A797C; Thu, 19 Feb 2015 10:22:44 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CB5A8F984; Thu, 19 Feb 2015 13:22:38 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 6DE24202F4; Thu, 19 Feb 2015 13:22:35 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Julian Reschke <julian.reschke@gmx.de>, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org
In-Reply-To: <54E50FC3.9080708@gmx.de>
References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Thu, 19 Feb 2015 13:22:35 -0500
Message-ID: <871tllbw2c.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/LGDXlrBAZztL29URJU8pXNczu28>
Cc: iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] 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 18:23:08 -0000

Hi Julian--

Thanks for the prompt response!  My own are inline below.

On Wed 2015-02-18 17:18:43 -0500, Julian Reschke wrote:
> On 2015-02-18 09:15, Daniel Kahn Gillmor wrote:
>> ...
>> Should recommend strong password-hashing on the server side
>> -----------------------------------------------------------
>>
>> The Security Considerations section acknowledges that passwords can be
>> stolen from servers, but does not encourage server operators to hash
>> stored passwords with a reasonable or strong algorithm.  This document
>> may not be the place to provide normative guidance on how to store
>> passwords to mitigate the exposure of a password table, but perhaps a
>> brief mention and an informative reference would be useful?  Many
>> systems (e.g. modern nginx and apache) use 1000 iterations of salted
>> MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1,
>> which are all terrible.
>>
>>   https://httpd.apache.org/docs/2.4/misc/password_encryptions.html
>>   http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file
>>
>> an informative reference might point to the Password Hashing
>> Competition, which documents sensible rationales for why you should use
>> strong password hashing, and how to know it when you see it:
>>
>>    https://password-hashing.net
>>
>> by comparison the digest draft has a lot more about how passwords should
>> be stored (even though Digest auth can offer only weaker protections for
>> the password store compared to Basic auth):
>>
>>   https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2
>> ...
>
> I would really like to avoid talking about threads that are generic to 
> password-based authentication. Optimally, the security area would have a 
> document that discusses exactly these kind of things so that other specs 
> can reference that. Does something like this exist?

These threats aren't generic to password-based authentication.  they're
specific to the *type* of password-based authentication used by HTTP
basic auth.  For example HTTP Digest and PAKE schemes are both
password-based, but have different properties, different requirements
for the password store, and different threats.

I don't know if there is an IETF document that describes
password-hashing best-practices or formats.  Maybe someone else knows?

> Or do you want to propose concrete text?

I don't have the bandwidth to craft something fancy right now, but
here's a first stab that you're welcome to carve up as you see fit, if
no IETF references are forthcoming:

   Servers and proxies requiring Basic Authentication must store user
   passwords in some form in order to verify the request's
   Authorization: header.  These passwords should be stored in such a
   way that a leak of the password table doesn't make them trivially
   recoverable.  This is especially when users are allowed to set their
   own passwords, since users are known to choose weak passwords and to
   reuse them across authentication realms.  While a full discussion of
   good password hashing techniques for HTTP Basic Authentication is
   beyond the scope of this document, server operators should make an
   effort to minimize risks to their users in the event of a password
   table leak.  For example, servers should not store user passwords in
   plaintext or as unsalted digests.  For more discussion about modern
   password hashing techniques, see [PHC].

 [PHC] https://password-hashing.net Password Hashing Competition

(i've used "should not" instead of RFC 2119 "SHOULD NOT" above because
this is not a recommendation about the on-the-wire protocol.  If anyone
thinks it should be elevated to an RFC 2119 "SHOULD NOT" i'd be happy to
see that happen, because this is seriously low-hanging fruit, and i'm
sure there are still operators out there disregarding it.

>> Should recommend constant-time server-side comparisons
>> ------------------------------------------------------
>>
>> Servers that implement basic auth should not leak information about
>> the stored password via timing of rejections.  For example, a server
>> that stored cleartext passwords (which is a bad idea anyway) should
>> mechanically compare the entire string instead of bytewise comparisons.
>> The attack here is an attacker who guesses credentials a byte at a time,
>> by making 256 initial guesses and seeing which of them gets back a
>> rejection faster than the other (and iterates down the list).
>>
>> This might be less of an issue for reasonable (non-cleartext) password
>> storage, but if we're not requiring strong password hashing, we should
>> at least require constant time comparisons.
>
> Do you seriously believe that the time for a string comparison is 
> relevant compared to the overhead of two network hops plus encapsulation 
> into HTTP messages?

If the transport framework (network hops plus encapsulation into HTTP
messages) has no jitter, then the ratio of timing between string
comparison and the transport framework overhead is irrelevant; an
attacker just cares about difference, not magnitude.  Even with some
small jitter, statistical analyses over many connections could yield
information.

Do i expect the transport framework to be jitter-free in the real world?
Usually, no.  But do you want the security of the scheme to depend on
the transport framework having jitter?

If this is a security consideration, would you rather say "deploy this
only over jittery transports" or "don't leak timing information when you
compare passwords"?  The latter seems simpler and clearer to me.


>> Should recommend padding the Authorization: response
>> ----------------------------------------------------
>>
>> When used behind HTTPS as recommended, TLS hides the username and
>> password presented.  However, it does not hide the length of the
>> username and password if the other parameters of the HTTPS request are
>> known.
>>
>> An active attacker who wants to learn the length of the victim's
>> username and password together for a particular basic auth realm could
>> force the user's browser to make HTTPS requests to a few different URLs
>> within the realm and see how large the packets are.
>>
>> This could be mitigated by including whitespace padding in the client's
>> Authorization: header itself up to some multiple of a blocksize (perhaps
>> 256B) to obscure the length.
>
> Actually, padding can happen anywhere in the message; it doesn't need to 
> be in this header field.

That's true, but padding the entire HTTP request to a standard blocksize
has different security properties than just padding this field to a
standard blocksize, because parts of the HTTP request could be under
control of the attacker.

For example, if Alice can make Bob's user agent fetch arbitrary URLs
from https://example.com/, then she can pass steadily increasing URLs to
Bob's user agent (e.g. https://example.com/a https://example.com/aa
https://example.com/aaa) and see at what point the size jumps a quantum.
Restricting the padding to the field that is not under attacker control
in any part should prevent this attack.

> It's an interesting idea; have you checked whether existing User Agents 
> do this?

I don't know whether any existing User Agents do this, sorry.

>> UTF-8 security considerations by reference: is this OK?
>> ------------------------------------------
>>
>> The Security Considerations section includes the UTF-8 security
>> considerations section by reference, but doesn't call out any specific
>> issues for implementers to be aware of.  the NFC canonicalization draft
>
> Intentionally.
>
>> also has Security Considersations section, which is not included by
>> reference:
>>
>>    https://tools.ietf.org/html/rfc5198#section-6
>
> I'll add that.

cool, thanks!


>> Interaction with proxies?
>> -------------------------
>>
>> There is only a passing mention of Proxy-Authenticate: and
>> Proxy-Authorization: headers, so one assumes that both mechanisms should
>> support this new auth-param.  It's not clear to me whether there are any
>> additional security or privacy implications when this is addressed to
>> proxies compared to origin servers.
>
> I'm not aware of any.
>
>> Section 2.2 ("reusing credentials") talks about the URI path (presumably
>> for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the
>> middle of that commentary.  It looks to me like "Proxy-Authenticate" is
>> not intended to be scoped by the URI path (there is no mention of "in
>> that space" in the sentence about Proxy-Authenticate in Section 2.2),
>> but this is kind of ambiguous.  Clarification would be good.
>
> To be frank, I don't know. My best guess is that it works exactly the 
> same, so I'll add "in that space" there as well.

This ambiguity worries me a bit; should we take this opportunity to
clear it up to match what happens in practice?  It seems like we should
have some people with operational experience on this who could provide
clarification here, but i'm not one of them.

>> Path matching?
>> --------------
>>
>> Nothing in the security considerations section talks about the threat
>> that motivates path matching for determination of which realm to use.
>> It might be useful to spell this out explicitly:
>>
>>   * A user agent that sends the Authorization: header to URLs outside the
>>     authentication scope as described in Section 2.2 may leak the user's
>>     credentials
>
> That applies to all schemes that use protection spaces and is mentioned 
> in <http://greenbytes.de/tech/webdav/rfc7235.html#protection.spaces> 
> already.
>
>> User Agent visibility and logout?
>> ---------------------------------
>>
>> Most RFCs don't talk at all about the human interface of the mentioned
>> tools.
>>
>> But this draft refers briefly to interaction between the user and the
>> User Agent (see step 1 on
>> https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6).
>> However, it provides no other guidance.  There are several additional
>> guidelines that make basic authentication more acceptable from a privacy
>> and security point of view for a typical web browser User Agent:
>>
>>   * user agents should indicate to the user when they are re-using the
>>     user's authentication credentials as described in section 2.2
>>     (indicating the realm, authentication scope, and user-id?)
>
> They don't right now. Do you believe that requiring it will have any 
> effect on existing UAs?

i don't know, but i'd certainly like to see that happen.  If it doesn't
happen, perhaps we need to mention in Security Considerations that User
Agents which do not indicate to the user when they are reusing the
user's credentials risk leaking those credentials without the user
knowing that it's happening?

>>   * user agents should not display the user's password anywhere by
>>     default
>
> That sounds pretty obvious.

I agree!  Maybe we don't need to say obvious things?

>>   * user agents should make it straightforward for users to clear their
>>     credentials for any <realm,authentication scope,user-id>.
>
> Define "straightforward".

That probably depends on the type of user agent, no?  as a suggestion,
this seems like it could be something that we encourage without
specifying concrete mechanism.

>> https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these
>> guidelines; perhaps this is another include-by-reference?
>
> All security considerations of RFC 7235 apply by definition, as this 
> spec is using the framework defined by RFC 7235. I don't believe that we 
> need to state this.

It wasn't immediately obvious to me that all security considerations of
RFC 7235 apply by definition, but now that you say it it makes sense.

Do you think that an implementor of HTTP basic auth with less experience
reading RFCs is going to understand that?

>> Other Considerations
>> ====================
>>
>> Deployment chicken-and-egg
>> --------------------------
>>
>> The server has no way of knowing that the client is trying to obey the
>> charset header.  For the servers mentioned in that do user-agent
>
> Actually, it could apply heuristics. I header detection of UTF-8 is 
> quire reliable.

What heuristics should it apply?  If there is a standard set of
heuristics we expect servers to use, we should put them in this
document.

>> sniffing, it's not clear how those servers could ever know to stop
>> relying on the user-agent, since the clients have no way of signalling
>> their intent to use UTF-8 for the Authorization header.  If the servers
>> don't know when to start accepting UTF-8 from these clients, then the
>> clients also have no way of knowing when they should switch over
>> themselves.  This strikes me as a recipe for stalled adoption, since
>> "user agents in the latter group" (from section B.3) will never use
>> UTF-8, even if they know about it.
>
> I don't see why the server can't just start accepting UTF-8 right away.


Because "User agents in the latter group will have to continue to do
what they do today", so the servers will need to interpret the response
in the same way.  If you mean to say that 'User agents in the latter
group will have to continue to do what they do today unless the server
has sent charset="UTF-8"' then please say so explicitly.


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.

       --dkg