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

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 20:07:54 +0100

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.

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Feb 2015 15:15:38 -0500

> microseconds. /me not convinced there's a problem here.

as long as the attacker can measure microseconds, and the network
exchange has small or regular-enough jitter to be accounted for with
statistical techniques, the size difference between these parts doesn't
matter to a timing attack.

  http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf

says:

   The resolution an attacker can time a remote host depends on how many
   measurements they can collect. Our simulated attacker using
   statistical hypothesis testing was able to reliably distinguish a
   processing time differences as low as 200ns and 30µs with 1,000
   measurements on the LAN and WAN respectively with. (See Section 6.)

Note that salted, hashed passwords where the attacker doesn't know the
salt are resistant to using a timing oracle like this to do byte-by-byte
guessing.  I still think it's simpler to just recommend that the tests
should be constant time.

> How would the attacker be able to modify fields in the request?

By changing the length of the requested URL (which is part of the
request), as described above.  For example, if you visit my website, i
can add new <img src="..."> elements trying to fetch whatever URLs i
want you to fetch.  If i can watch your traffic, i can compare the sizes
of those requests.

> (It seems to be as relevant for cookies, no?)

It does seem relevant for cookies, but this draft isn't about cookies :)
If there's no document to point to, we should still acknowledge the
concern here, no?

> was likely encoded in UTF-8.

Some binary strings are valid in both character encodings, though,
right?  For example, "c3 a1 62 63" in UTF-8 is "ábc", but in ISO-8859-1,
it is "Ã¡bc" So if my password is non-ASCII in the first place, it could
very well match the UTF-8 encoding even though i've intended another
one.

So maybe the heuristic should be: even if the UTF-8 decode succeeds, the
server could try its fallback decoding mechanism if the UTF-8 version of
the password doesn't match.  (fwiw, my understanding is that facebook
checks common accidental variations on the entered password during their
(non-basic-auth) login process.  so if my password is b4nanAs, but i
type B4NANaS or b5nanAs, facebook might let me in anyway)

Is this advisable?  What are the risks of testing two variants of the
password against the password table?  I haven't thought this through
fully, but it seems like it would be a relevant consideration.

In the absence of a signal from the client about their choice of
encoding, documenting these heuristics and recommending them seems like
a useful way to facilitate adoption and uniformity among servers
implementing this spec.

> Maybe just drop the second half of the paragraph and only mention the 

If we drop the second half, i'd still like to know what kind of steps a
server should take to guard against the possibility of counterfeiting.
If we don't have any recommendations or external references, an
unactionable SHOULD seems troublesome.

Regards,

   --dkg

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 21:34:01 +0100

> guessing.  I still think it's simpler to just recommend that the tests

I'm sorry, I'm not convinced. What do others think?

> want you to fetch.  If i can watch your traffic, i can compare the sizes

But the actual request is still under control of the browser.

> If there's no document to point to, we should still acknowledge the

Well, I'm actually not concerned yet. If this was a problem in practice 
then we should have evidence, for instance, by finding padding code in 
user agents. I'm not saying there is none, but I do believe that if you 
are serious about this you ought to research yourself what the current 
state of implementations is.

> very well match the UTF-8 encoding even though i've intended another

Any octet sequence is valid in ISO-8859-1, true.

If the server doesn't know whether a certain sequence is UTF-8 or 
ISO-8859-1, it simply could try both.

> fully, but it seems like it would be a relevant consideration.

It might.

> In the absence of a signal from the client about their choice of

...which we can't have unless we switch to a new auth scheme...

> a useful way to facilitate adoption and uniformity among servers

I'll think about what advice we can give here.

> unactionable SHOULD seems troublesome.

I'd just say

"Basic Authentication is also vulnerable to spoofing by counterfeit 
servers. If a user can be led to believe that he is connecting to a host 
containing information protected by Basic authentication when, in fact, 
he is connecting to a hostile server or gateway, then the attacker can 
request a password, store it for later use, and feign an error. This 
type of attack is not possible with other authentication schemes, such 
as Digest Authentication."

and leave it at that.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 19 Feb 2015 22:49:23 +0100

>I'm sorry, I'm not convinced. What do others think?

I would prefer to point to an existing document for considerations such
as this one, and I do not think it is entirely obvious for implementers
of the scheme that comparison should take time independent of the length
of the credentials, so including something brief about this makes sense
to me.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Feb 2015 17:35:38 -0500

Daniel,

Thanks for much for the detailed review and discussion!  It may be helpful
to document some of these concerns in another draft and see what we can do
to improve going forward.  Would you be up for that?

Julian,

Thanks for the discussion.  I think we are close to addressing the concerns
raised and that we can let some slip for this draft since it was meant to
be an update to address internationalization concerns.  It does already say
this isn't a secure choice and this review adds more reasons for that
concern.

The rest is inline.

> I'm sorry, I'm not convinced. What do others think?

I think it's okay to leave out mention of side channel attacks like this
timing attack.  It might be useful in a follow up draft or if this were
earlier in the process.

> then we should have evidence, for instance, by finding padding code in user
> agents. I'm not saying there is none, but I do believe that if you are
> serious about this you ought to research yourself what the current state of
> implementations is.

I think it's okay to leave this out for now as well, may be material for
another draft.  Basic is used in lots of places still, so understanding all
the bad things about it may help inspire people to switch to something else
(says optimistic SecAD).

> ...which we can't have unless we switch to a new auth scheme...

Another draft might be good...

> containing information protected by Basic authentication when, in fact, he
> is connecting to a hostile server or gateway, then the attacker can request
> a password, store it for later use, and feign an error. This type of attack
> is not possible with other authentication schemes, such as Digest
> Authentication."
>
> and leave it at that.

The text proposal looks reasonable. I'll go back through the original
review to make sure nothing was missed.

Thanks again!!

Kathleen

>
>
> Best regards, Julian
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Feb 2015 17:54:53 -0500

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

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

> 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.
>
Good, thanks for this addition as well.

> 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.
>
> 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.
>
> An implementor of this spec will need to read and understand RFC 7235. So,
> yes.
>
>  Other Considerations
>>>> ====================
>>>>
> 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.
>

-- 

Best regards,
Kathleen

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Feb 2015 15:06:42 -0800

> I'm sorry, I'm not convinced. What do others think?

It is possible to run a timing attack on a remote server that uses
any form of authentication scheme.  However, the likelihood of detecting
within the attack a difference of matching N characters vs N+1 characters
is incredibly small (usually less than 1 nanosecond) unless the matching
algorithm itself is unusually complicated.

In any case, we can't just recommend that the tests should be constant time.
Very few people understand what that means, even in a security discussion.
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.

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.

[...]

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

> "Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with other authentication schemes, such as Digest Authentication."

Er, it is possible with Digest, but less productive (the credentials are
only usable for as long as the nonce works).

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Feb 2015 16:10:22 -0800

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

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

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

....Roy

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Feb 2015 18:39:30 -0500

--dkg

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 14:32:28 +0100

On 2015-02-19 19:22, Daniel Kahn Gillmor wrote:> ...
 > sure there are still operators out there disregarding it.

I have added very similar text with 
<http://trac.tools.ietf.org/wg/httpauth/trac/changeset/125>):

 >>    Servers and proxies implementing Basic Authentication need to store
 >>    user passwords in some form in order to authenticate a request.
 >>    These passwords ought to be be stored in such a way that a leak of
 >>    the password data doesn't make them trivially recoverable.  This is
 >>    especially important when users are allowed to set their own
 >>    passwords, since users are known to choose weak passwords and to
 >>    good password hashing techniques is beyond the scope of this
 >>    document, server operators ought to make an effort to minimize risks
 >>    to their users in the event of a password data leak.  For example,
 >>    servers ought to avoid storing user passwords in plaintext or as
 >>    unsalted digests.  For more discussion about modern password hashing
 >>    techniques, see the "Password Hashing Competition"
 >>    (<https://password-hashing.net>).

Thanks for the proposal!

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 14:52:50 +0100

Thanks for the explanation, Roy. I have changed that paragraph to:

>    Basic authentication is also vulnerable to spoofing by counterfeit
>    servers.  If a user can be led to believe that she is connecting to a
>    host containing information protected by Basic authentication when,
>    in fact, she is connecting to a hostile server or gateway, then the
>    attacker can request a password, store it for later use, and feign an
>    error.  Server implementers ought to guard against this sort of
>    counterfeiting; in particular, software components which can take
>    over control over the message framing on an existing connection (for
>    instance, "NPH" ("non parsing of headers") scripts) need to be used
>    carefully or not at all.

(<http://trac.tools.ietf.org/wg/httpauth/trac/changeset/126>)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 15:00:25 +0100

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

As this advice applies is not specific to Basic: how about putting this 
on our TODO list for RFC 7235bis?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 16:49:28 +0100

> a useful way to facilitate adoption and uniformity among servers

I looked at this some more, and it seems that the general question 
applies to the third paragraph in B.2 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpauth-basicauth-update-06.html#rfc.section.B.2.p.3>):

    Finally, origin servers that need to support non-US-ASCII characters
    and can use the UTF-8 character encoding scheme can opt in as
    described above.  In the worst case, they'll continue to see either
    broken credentials or no credentials at all (depending on how legacy
    clients handle characters they cannot encode).

I propose to expand the problem description, and to mention that servers 
that need to support a mix of clients can attempt a "try both" strategy:

    Finally, origin servers that need to support non-US-ASCII characters
    and can use the UTF-8 character encoding scheme can opt in by
    specifying the charset parameter in the authentication challenge.
    Clients that do understand the charset parameter will then start to
    use UTF-8, while other clients will continue to send credentials in
    their default encoding, broken credentials, or no credentials at all.
    Until all clients are upgraded to support UTF-8, servers are likely
    to see both UTF-8 and "legacy" encodings in requests.  When
    processing as UTF-8 fails (due to a failure to decode as UTF-8 or a
    mismatch of user-id/password), a server might try a fallback to the
    previously supported legacy encoding in order to accomodate these
    legacy clients.  Note that implicit retries need to be done
    carefully; for instance, some subsystems might detect repeated login
    failures and treat them as potential credentials guessing attack.

(<http://trac.tools.ietf.org/wg/httpauth/trac/changeset/129>).

WDYT?

Best regards, Julian

PS: slightly related: this section talks about origin servers instead of 
servers (-> proxy authentication); I'll fix that as well.