Closed Bug 915745 Opened 12 years ago Closed 10 years ago

HTTP Digest Authentication in Firefox is vulnerable to Man-In-The-Middle attack described in RFC 2617

Categories

(Core :: Networking, defect)

23 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: thenlich+bugmoz, Unassigned)

Details

(Keywords: csectype-other)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 20130814063812 Steps to reproduce: 1. Browse to a site requesting HTTP Basic Authentication 2. Browse to a site requesting HTTP Digest Authentication Actual results: The authentication dialogs presented in 1 and 2 are identical. A user can not distinguish whether the plain-text password is transmitted over the network or not. This opens the possibility for an attack described in RFC 2617 4.8: "... MITM attack would be to remove all offered choices, replacing them with a challenge that requests only Basic authentication, then uses the cleartext credentials from the Basic authentication to authenticate to the origin server using the stronger scheme it requested." Nowadays this can easily be easily exploited e.g. in public Wi-Fi networks, even by attackers without a multi-billion dollar budget. Expected results: According to RFC 2617 4.8, "User agents should consider measures such as presenting a visual indication at the time of the credentials request of what authentication scheme is to be used, or remembering the strongest authentication scheme ever requested by a server and produce a warning message before using a weaker one. It might also be a good idea for the user agent to be configured to demand Digest authentication in general, or from specific sites."
Component: Untriaged → Networking
Product: Firefox → Core
We can't "demand Digest authentication in general" since some sites don't support it. We could, I suppose, remember which sites (pages? realms?) have used it in the past and then demand it when we re-visit those. I don't think announcing the auth type on the dialog will help the average user -- they'd probably not notice the difference, and if they did they would have no clue what "Basic" and "Digest" meant or if it changed from visit to visit. The IE and Chrome teams seem to have come to a similar conclusion because I don't see a difference in their dialogs either. Essentially browser vendors have come to the conclusion that it's possible to education users that "TLS/padlock is secure" but not finer distinctions between auth types. In practice few web sites use HTTP auth, preferring password forms in content where TLS really is the only protection you've got. And if you have an encrypted TLS channel you don't have to worry about a MITM replacing Digest auth with Basic. I'm confirming because the 1999 spec does say this but we might just wontfix this as irrelevant to today's web. We don't need to keep this bug hidden if the attack is described in a specification
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: csec-other
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.