New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 544244
Owner: ----
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Sign in to add a comment

Issue 606392: HTTP Basic Auth login message is no longer shown

Reported by, Apr 25 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Steps to reproduce the problem:
1. Visit
2. Try to figure out which login credentials to use

What is the expected behavior?
Chromium should display the HTTP authentication message sent by the server.

What went wrong?
Chromium used to show the server's HTTP authentication message like other browsers also still do. This makes it easier for the user to figure out which credentials they have to enter. Now, it appears that Chromium and other Chromium-based browsers (such as Vivaldi) always show a generic message.

Did this work before? Yes Not sure, I think a year ago it still worked.

Chrome version: 45  Channel: n/a
OS Version: Xubuntu 15.10
Flash Version: 

Yes, using HTTP basic auth like on this page is probably not what the protcol was intended to be used for, but it's an almost perfect way to get rid of spam bots. However, right now Chromium users always have to take a detour to a 401 page to figure out how to bypass the login prompt.

Comment 1 by, Apr 25 2016

Components: Internals>Network>Auth
Status: Assigned (was: Unconfirmed)
Chromium is no longer displaying the realm string for basic auth.

It looks like this was an intentional change from

Over to Chris to confirm whether this is the case.

Comment 2 by, Apr 25 2016

Components: Security>UX
Yes, it is intentional. The basic idea is that we want for important/security-sensitive UX surfaces to show only information we can verify; the Realm string is arbitrary and can be used to phish or otherwise confuse.

See also for more discussion.

However, I am open to reconsidering the decision. I do believe the current status was the right decision, and that the uses of the Realm string are marginal. (Surely, at least one spam-bot knows to try substrings of the Realm string? Surely, spam is best solved at the content layer? et c.)

But, I am open to changing, not dogmatic. :)

felt, meacer, cbentzel: Any thoughts?

Comment 3 by, Apr 25 2016

I understand your security concerns, but I think that this is not entirely thought-through: You are already serving server-generated content that is at least of the same security sensitivity as a HTTP authentication - namely any login page on the internet. An attacker can always insert any arbitrary string anywhere they want (e.g. "enter your GMail login credentials here"), not just on HTTP authentication prompts. For example, they can always prepend a website containing the same information as the Realm string before redirecting the user to the login screen - it has the same effect. So the intention is good, but I don't think it actually solves the problem.

Firefox explicitely mentions that the Realm text is sent by the website, not by Firefox itself. Would that be an option for Chromium? Something along the lines of " sends the following login information: <Realm text>".

> Surely, at least one spam-bot knows to try substrings of the Realm string? 

So far I have not encountered any, and I have been using this method for years.

> Surely, spam is best solved at the content layer? etc.

In an ideal world, yes (but in an ideal world we also wouldn't have any spam :). In the real world, my time my is too precious to manually combat spam content, hence I will choose the easiest method that will keep away the majority of spam bots. I haven't had to delete a single spam bot since I started using this mechanism. Naturally, this would be different if this mechanism was used but thousands of other (big) websites, but at the moment it's an effective measure.

Comment 4 by, Apr 25 2016

I'm inclined to keep the realm elided as well. We could look to see if this has had an impact on successful basic auth logins though to be sure.

Comment 5 by, Apr 25 2016

Labels: -OS-Linux -Pri-2 OS-All Pri-3

Comment 6 by, Apr 25 2016

Regarding the related issue you mentioned: You have already lost once the MITM attack is successful. A MITM-attacker can not only inject a custom WWW-Authenticate header, if they feel like it they can inject an entire custom Google login page too!

Comment 7 by, Apr 25 2016

More thoughts:
- The MITM attacker could inject some JavaScript code that adds HTML elements that look exactly like Chromium's HTTP auth window (one reason why I don't like in-browser overlays)
- An educated user would probably recognize the attack in both cases.
- A non-educated user can fall for both the old and new version of the dialog: They get a login prompt that tells them that asks for a password - now in the new version they wonder which password that could be, and they think "I'm on YouTube, so maybe I should enter my YouTube (GMail) credentials!".

Comment 8 by, Nov 22 2016

Labels: Team-Security-UX

Comment 9 by, Nov 22 2016

Components: -Security>UX

Comment 10 by, Jan 6 2017

Owner: ----
Status: Available (was: Assigned)

Comment 11 by, Jan 6 2017

Mergedinto: 544244
Status: Duplicate (was: Available)

Sign in to add a comment