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

[Daniel Kahn Gillmor <[e-mail]>]

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.

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

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.

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

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

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.

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

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