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

>
> This part of the thread resulted in a few more changes, I'm ok with them
as noted below and just want to track this and add an RFC editor note on
the reference concern.

Thanks!

On Thu, Feb 19, 2015 at 2:07 PM, Julian Reschke <julian.reschke@gmx.de>
wrote:

> On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:
>
>> 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.
>>
>
> I like the text, and I'm ok with including it or a variation of it. I'm
> not 100% convinced that the RFC Editor will be ok with the citation.

OK, this looks good as well, thanks.  We'll figure out the reference as we
go.  I can make an RFC editor note on it so we don't forget to figure it
out.

>
>
>  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.
>>
>
> The network exchange will be take milliseconds. The string comparison
> microseconds. /me not convinced there's a problem here.
>
>
>
>  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.
>>
>
> How would the attacker be able to modify fields in the request?
>
> I think it would be great to have a document that describes these threats
> and how to mitigate them; in particular comparing HTTP/1.1 and 2, but I
> seriously doubt this document would be the right place to do this.
>
> (It seems to be as relevant for cookies, no?)
>
>
>
>  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!
>>
>
Good, thanks for this addition as well.

>
>>
>>  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.
>>
>
> Nor am I.
>
> I do agree that proxy authentication needs better documentation, but
> that's a problem of RFC 7235, not this spec.
>
>
>  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?
>>
>
> We could say that (text welcome), but I seriously doubt it will affect
> what software does. The current trend is to remove as much UI as possible
> (or even all on mobile), so asking for this indicator is really wishful
> thinking.
>
>     * 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.
>>
>
> Again, we're talking about code that has been written almost 20 years ago.
> New advice on nice-to-haves will not have any effect on these
> implementations.
>
>  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?
>>
>
> An implementor of this spec will need to read and understand RFC 7235. So,
> yes.
>
>  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.
>>
>
> I don't *expect* servers to use heuristics.
>
> That being said, the heuristics are quite simple: try to decode the octets
> with a strict UTF-8 decoder, and if that doesn't fail the input was likely
> encoded in UTF-8.
>
>  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.
>>
>
> No, that's not what I meant.
>
> By "accepting UTF-8" I mean "trying to decode as UTF-8" in addition to
> what the server is already doing; basically a trial-and-error approach.
>
>  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.
>
> Maybe just drop the second half of the paragraph and only mention the
> thread itself?
>
> Best regards, Julian
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>

-- 

Best regards,
Kathleen