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

[Julian Reschke <[e-mail]>]

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?

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

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

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

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.

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

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.

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

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

> encoding, documenting these heuristics and recommending them seems like
> a useful way to facilitate adoption and uniformity among servers
> implementing this spec.

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

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

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