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

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

On Feb 19, 2015, at 12:34 PM, Julian Reschke wrote:
> On 2015-02-19 21:15, Daniel Kahn Gillmor wrote:
>> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote:
>>> The network exchange will be take milliseconds. The string comparison
>>> 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.
> 
> 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.

[...]

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

>>> 
>>> Maybe just drop the second half of the paragraph and only mention the
>>> thread itself?
>> 
>> 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.
> 
> 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."

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

....Roy