Not an expert in our HTTP auth code overall, but I don't see any metrics for specifically digest auth vs. other HTTP auth types either.
As an upper bound, I wouldn't expect HTTP auth of any form to be common. This whole space is mostly a legacy feature as far as the web is concerned. I doubt usage would ever completely fall off, but it's not exactly a preferred path, or a space that sees much active work. Making modern hashes available for Digest seems reasonable enough, I suppose, but I wouldn't want to spend more time on it than that. :-) But I couldn't find good metrics for the upper bound either. Net.HttpResponseCode says how often we see 401 and 407 response codes (very rarely), but that's a little misleading. If I recall (not an HTTP auth expert), for the simpler auth types (Basic and Digest), cached credentials are sufficient to preemptively send a (Proxy-)Authorization header. That means we'll only see a 401 or 407 on the first go around, up to some interesting rules around which paths an auth entry is scoped to. In terms of breakage risk, since this protocol is server-offer / client-select, the client never sends the list of values it supports. That means only servers that actually claim to support the new hashes will see any change at all. So the risk is limited to early-adopting servers that have adopted the new thing but gotten it wrong. Or if we got it wrong. :-) (No particular opinions on my end as to whether that makes it worth flag-protecting.) On Mon, Jun 26, 2023 at 10:46 AM Rick Byers <[email protected]> wrote: > Hi Deomid, > Thanks for the contribution! Do you know if chromium has any metrics on > how common digest auth is? I took a quick look and didn't find one myself. > +David > Benjamin <[email protected]> also. Technically all new APIs (which > includes protocols) require a killswitch flag > <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> > since > we've seen even new APIs break websites sometimes (eg. in this case > presumably it would be from a misconfigured server). But if we have data > showing the usage of digest auth is small / insignificant enough, I'd > personally be receptive to an argument that that is unnecessary extra > bureaucracy. > > Also it would be nice to know if WebKit has an opinion on this, could you file > a position request > <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u> > please? > > Thanks, > Rick > > On Wed, Jun 21, 2023 at 3:31 PM Deomid "rojer" Ryabkov <[email protected]> > wrote: > >> Hi Daniel, >> >> I do not anticipate immediate impact. By and large, this is not currently >> used because the most popular browser engine doesn't support it. So people >> just use MD5, as in the bad old days. >> If we ship this tomorrow, nothing changes: servers still send legacy MD5 >> challenges, which we continue to support. >> As awareness of SHA-256 support by Chrome/Blink-based browser spreads, I >> expect service administrators to gradually start transitioning away from >> MD5. >> The RFC specifies use of multiple algorithm challenges by sending >> multiple WWW-Authenticate headers, so there's a good transition path there >> for service admins (send both SHA-256 and MD5 challenges, phase out MD5 >> eventually). >> I verified that with my current code this works as specified (order of >> headers specifies server's preference). >> Firefox already supports SHA-256, so there's already a capable browser in >> the wild, but since it's a minority there isn't much use yet. >> As far as deviating from Firefox in also supporting SHA-512-256 and >> userhashing, it's again a no-op initially: these won't be used unless >> servers explicitly specify that they can be used (for example, for lighttpd >> there's an explicit option to enable username hashing, off by default). >> If Firefox catches up and also implements these, then we might start >> seeing adoption. >> >> >> On Wed, 21 Jun 2023 at 11:18, Daniel Bratell <[email protected]> wrote: >> >>> I am missing the compatibility picture here. How will this affect >>> existing web pages, and what happens to browsers that do not support this >>> is we add support? >>> >>> /Daniel >>> On 2023-06-20 18:13, Deomid "rojer" Ryabkov wrote: >>> >>> Contact emails [email protected] >>> >>> Explainer None >>> >>> Specification https://datatracker.ietf.org/doc/html/rfc7616 >>> >>> Summary >>> >>> https://datatracker.ietf.org/doc/html/rfc7616 specifies SHA-256 and >>> SHA-512-256 algorithms for the HTTP digest authentication scheme, in >>> addition to the obsolete and insecure MD5. It also specifies way of >>> concealing the username, provided that server supports it. Firefox supports >>> algorithm=SHA-256 since 93, but not SHA-512-256 or username hashing. >>> https://chromium-review.googlesource.com/c/chromium/src/+/4611879 is >>> the pending CL. >>> >>> >>> Blink component Blink>Network >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>> >>> TAG review None >>> >>> TAG review status Not applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> *Gecko*: Shipped/Shipping ( >>> https://bugzilla.mozilla.org/show_bug.cgi?id=472823) >>> >>> *WebKit*: No signal >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> >>> Debuggability >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)? Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? No >>> >>> Flag name >>> >>> Requires code in //chrome? False >>> >>> Tracking bug >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1160478 >>> >>> Estimated milestones >>> Shipping on desktop 116 >>> Shipping on Android 116 >>> >>> Anticipated spec changes >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5139896267702272 >>> >>> Links to previous Intent discussions >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> -- >>> Deomid "rojer" Ryabkov >>> [email protected] >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >> >> -- >> Deomid "rojer" Ryabkov >> [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaAeJ5776vm1%3DX-tzxH9FhHGK05q-uGMCTJjP511ho84TA%40mail.gmail.com.
