a quick survey of my open tabs shows 4 of them have non-query portions of the URL that are things I would expect an attacker to have to guess - even if she were familiar with the same application. So the current status of things seems worthwhile, despite the compression hit. (That's the whole basic tradeoff of hpack vs gzip anyhow.) -P On Mon, Jul 21, 2014 at 9:37 AM, James M Snell <jasnell@gmail.com> wrote: > Well, hopefully we'd be hard pressed to find many real world examples of > passwords in the query string, but there are many examples involving API > keys and authorization tokens. These, fortunately, tend to have a greater > entropy than passwords but are still quite dangerous. Whether separating > them out to a new :query field makes them more vulnerable, I have no idea. > Would be interesting to test. > On Jul 21, 2014 6:28 AM, "Eric Rescorla" <ekr@rtfm.com> wrote: > >> >> >> On Mon, Jul 21, 2014 at 6:20 AM, Martin Thomson <martin.thomson@gmail.com >> > wrote: >> >>> On 21 July 2014 00:53, Willy Tarreau <w@1wt.eu> wrote: >>> > >>> > I'm not sure what you mean, we're speaking about having a single :query >>> > for whatever follows the question mark, right ? If so, all the params >>> > must be tried as a single block. >>> >>> Yes, but there could be cases where the combination of path and query >>> contain sufficiently high entropy in combination, but one or other >>> contains insufficient entropy on its own to resist guessing attacks. >>> >> >> I concur with Martin's analysis >> >> Consider the case where we have sensitive information split between the >> path and the query. E.g. >> >> https://login.example.com/ekr?<password> >> >> If the username is unknown, this lets them be guessed independently. >> >> -Ekr >> >>
Received on Monday, 21 July 2014 13:45:21 UTC