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

["Roy T. Fielding" <[e-mail]>]

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

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,

....Roy