standards-positions
standards-positions copied to clipboard
WebKit
RFC7616: SHA-256 support for digest authentication
WebKittens
No response
Title of the spec
RFC7616: SHA-256 support for digest authentication
URL to the spec
https://datatracker.ietf.org/doc/html/rfc7616
URL to the spec's repository
No response
Issue Tracker URL
https://bugs.chromium.org/p/chromium/issues/detail?id=1160478
Explainer URL
No response
TAG Design Review URL
No response
Mozilla standards-positions issue URL
No response
WebKit Bugzilla URL
No response
Radar URL
No response
Description
Blink intends to add support for modern digest algorithms for the HTTP digest authentication, as specified in RFC 7616. No major impact is expected, and Firefox already supports them since 93. I've been asked to seek WebKit's opinion on the matter. For reference, the Chrome status entry is here, blink-dev discussion thread is here. Proposed code change is here.
Discussing this with colleagues it's been our hope to eventually be able to deprecate HTTP authentication. So it's a bit surprising to see continued investment from Google.
Could you please elaborate on the motivation behind this?
So it's a bit surprising to see continued investment from Google.
This issue (and the related intent) wasn't sent by a Google employee - so the "from: Google" label is incorrect.
Thank you for the correction! I guess we should be following blink-dev to figure out what Google thinks of this.
@annevk yeah, i'm not affiliated with Google. HTTP digest authentication is still useful and being useful on small footprint devices as an easy way of securing access to a web UI. in particular, TLS+basic is usually not available there due to lack of a trusted certificate, TLS implementation or both, and digest gives at least a modest improvement over plain basic or form-based authentication. our company produces small-footprint devices, and i would like us to eventually move to a better digest algorithm than MD5, that's all.
It's not clear to me how you can be safe from network attackers without TLS?
with plain basic or general cookie auth network attacker gains persistence: they can intercept the credentials and maintain access even after they no longer have access to network traffic. so it's not absolute protection but fair bit better than sending credentials in plain.
HTTP authentication is better: it's simple, doesn't require Javascript (to hash), uses a native dialog, blocks screensharing view, rotates nonce regularly, etc.
And in addition to what @rojer said, the attacker also doesn't find out the password itself with digest auth.
(Some form of local TLS standard would be nice, but I'm not aware of anyone even working on that.)
Per https://groups.google.com/a/chromium.org/g/blink-dev/c/cJH3JJY_tTY/m/0_uCOheRDQAJ it seems Chromium did move ahead with this. @ekinnear thoughts? Still not really convinced about this. E.g., if I had to prioritize efforts and pick between this and "local TLS", I'd prioritize local TLS.
(It seems Chromium WONTFIXED SHA-512-256 so I'll remove that from OP. No need to consider it.)
safari support is probably the last thing preventing it from being widely used and improving the security of internal web interfaces. it's almost trivial in terms of implementation (speaking from the chrome/blink experience).
if I had to prioritize efforts and pick between this and "local TLS", I'd prioritize local TLS.
It's not clear how local TLS would even work (somehow you need to securely communicate the correct pubkey to the user), while this is very trivial to add today.
Discussing this with colleagues it's been our hope to eventually be able to deprecate HTTP authentication. So it's a bit surprising to see continued investment from Google.
Could you please elaborate on the motivation behind this?
Strong digest auth is required by HTTPS proxies, where credentials for the HTTPS proxy must traverse the network in clear text.
The userhash feature is also very important so that usernames of HTTPS proxies aren't revealed in plain text.
