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 72 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 544244: HTTP basic auth credentials prompt should make the origin stand out more

Reported by, Oct 16 2015

Issue description

Steps to reproduce the problem:
   Here is what I see when visiting on a Nexus 7 running Android 5.1.1 with a man in the middle injecting a WWW-Authenticate header.


Sent: Friday, October 16, 2015 8:37 AM
Subject: [5-5913000009006] other in Chrome 46.0.2490.76

Thanks for the vulnerability report.
This email confirms we've received your message. We'll investigate and get back to you once we've got an update.
Google Security Bot

Report Details
Email Subject: [5-5913000009006] other in Chrome 46.0.2490.76
Category: other
Product: Chrome 46.0.2490.76
Cid: 5-5913000009006
Chrome on Android doesn't make it clear that the server supplied realm in HTTP basic auth requests is not to be trusted. The Chrome credentials prompt is vulnerable to phishing because of this. This web site is crap so I can't include a screenshot. I'll reply to the auto generated email with one.

This report is one of two or three independent issues that support phishing for Google credentials on YouTube.

Attack scenario:

What is the expected behavior?

What went wrong?
See above

Did this work before? N/A 

Chrome version: 46.0.2490.76  Channel: stable
OS Version: 5.1.1
Flash Version:
Basic Auth.jpg
162 KB View Download

Comment 1 by, Oct 16 2015

 Issue 544240  has been merged into this issue.

Comment 2 by, Oct 16 2015

Labels: -Arch-x86_64
Summary: HTTP basic auth credentials prompt should make it clear if the connection is not private (was: HTTP basic auth credentials prompt is vulnerable to phishing)
Thanks for the report.

The realm is controlled by the page, but the auth dialog clearly mentions origin ( From the merged bug, it seems like you are saying the dialog should be more explicit that this connection isn't encrypted, so renaming the bug.

Unless I'm missing anything, this isn't a security vulnerability but an improvement, so I'll drop the view restriction.

Comment 3 by, Oct 16 2015

Labels: -Restrict-View-SecurityTeam -Type-Bug-Security Cr-Security-UX Type-Feature

Comment 4 by, Oct 16 2015

Labels: -OS-Android OS-All
+palmer who added the origin to this prompt before and was looking at exposing connection info here

Comment 5 by, Oct 16 2015

It is important to look at the example UI I posted from Chrome on Android.  This is the actual Chrome YI, not a mockup.  If you don't believe that a typical user will enter credentials, you are optimistic.  While the UI indicates, though not very clearly, that some of what follows is from the server, it doesn't even suggest that this text can't be trusted.  I would go further and claim that a typical user may assume that the server supplied text ends at the first period.  To make this more clear, the server text should be in a separate text control with a clear boundary and not inline with the browser supplied text.

Comment 6 by, Oct 16 2015

And the new title is wrong.  544240 and 544244 are two distinct and unrelated issues with the same UI.  This one has nothing to do with HTTP vs. HTTPS.

Comment 7 by, Oct 16 2015

Both the origin in the omnibox and the auth dialog in your screenshot indicate that this is not an HTTPS page. We can certainly make the origin stand out more in the dialog, which is why this is labeled as an improvement.

Comment 8 by, Oct 16 2015

This is not an HTTP vs. HTTPS issue.

See attached landscape screenshot where address bar is obscured.
112 KB View Download

Comment 9 by, Oct 16 2015

Status: Available
Summary: HTTP basic auth credentials prompt should make the origin stand out more (was: HTTP basic auth credentials prompt should make it clear if the connection is not private)
Yes, understood. This is a problem of the origin not being displayed prominently enough on the dialog and mixing it with site supplied text. I've re-titled the bug once again.

The auth dialog obscuring the omnibox seems like another problem though, we should fix that. Can you file it as a separate bug?

Comment 10 by, Oct 16 2015

And, you appear to be applying the metric "can a browser developer recognize whether this is secure" when the correct metric is "would a bon-technical user with no understanding of how things work understand that this is spoofed/not secure"  Spoofed is the issue in this bug despite the inappropriate title change and not secure is the issue with 544240 that is distinct from this one.

To be clear, you can do whatever you want with the origin.  it's a waste of time.  the origin is important but only to tell a typical user who is asking or gets the answer.  it would do nothing to inform my mother, my non-engineer friends, etc whether this is secure or not.  They don't really understand HTTP vs. HTTPS.  The lock is understood but I bet not well.

The origin does nothing for phishing potential.  You would be incorrect if you assume that a user understands this.  I can just add text stating that this request is secure and a typical user will believe it simply because it says it right there in the prompt.

Comment 11 by, Oct 16 2015

Filed  bug 544272  for the keyboard issue.

Comment 12 by, Oct 16 2015

And duped it into bug 544267.

Comment 13 by, Oct 19 2015

Labels: Cr-Internals-Network-Auth Cr-UI-Auth
Status: Assigned

Comment 14 by, Oct 23 2015

@palmer: I have a CL at that separates origin from site provided text. It lacks Android and OSX views code for now, feel free to take it over.

Comment 15 by, Oct 28 2015

I looked at the sample screenshot and don't believe it sufficient.  The realm string is still displayed inline.  The realm could contain a quote to make the separation unclear.  I think the realm text should be in a separate text field, indented to separate further. There should be some text informing the user that this text should not be trusted or only be trusted if the origin site is trusted.  It would also be good to add a lock icon if the site is secure and text, like Edge and IE, warning when the site is not secure and the name and password are transmitted in the clear.

Comment 16 by, Oct 28 2015

The realm is already separated from the top text, grayed out, and wrapped in quotes in the screenshot:

Adding a separate textbox or a warning message for the realm string won't make anything clearer, it will add more clutter for marginal benefit.

I'll defer any additional new strings (e.g. basic auth over HTTP) to palmer@.

Comment 17 by, Nov 19 2015

I don't think we need new strings or anything. meacer is going to land the patch that results in the UX shown in #16.

Here are screenshots of what Firefox and Edge look like. Note that Firefox offsets the site-controlled information with quotes, while Edge does not. So, after meacer's patch, Chrome would show the site-controlled string with the least prominence and the most distinction between it and the browser-controlled text (of the 3 browsers).

However, I wonder if perhaps we don't need to/shouldn't show the realm string at all. felt, what do you think? I'd kind of like to get rid of it.
22.2 KB View Download
49.7 KB View Download

Comment 18 by, Nov 21 2015

CL in progress at Here are the Views and Cocoa screenshots for secure and non-secure. Android coming on Monday.
Screen Shot 2015-11-20 at 5.39.51 PM.png
52.1 KB View Download
Screenshot from 2015-11-20 17:48:52.png
15.6 KB View Download
Screenshot from 2015-11-20 17:48:22.png
18.5 KB View Download
Screen Shot 2015-11-20 at 5.41.23 PM.png
20.9 KB View Download

Comment 19 by, Nov 24 2015

Here are the Android screenshots.
104 KB View Download
109 KB View Download

Comment 20 by, Dec 8 2015

Project Member
The following revision refers to this bug:

commit d4fe8211476a0bba1a347204e430aa283c2e7d7f
Author: palmer <>
Date: Tue Dec 08 01:07:13 2015

Do not show untrustworthy strings in the basic auth dialog.

Browser chrome should display only trustworthy or verified strings.


Review URL:

Cr-Commit-Position: refs/heads/master@{#363658}


Comment 21 by, Dec 8 2015

Status: Fixed

Comment 22 by, Jan 27 2016

I consider the new behaviour a bug. There are websites that use the realm to tell the user what kind of auth they should enter; e.g. a simple spam protection measure may be to require a fixed username and password mentioned in the realm string ("Log in as not_a_spammer with password nospam”).

Comment 23 by, Jan 29 2016

Status: Started
I'm re-opening this bug so we can consider what to do about #22. felt, estark, egm, asanka, cbentzel: Any ideas or concerns? Here are mine:

* The HTTP Auth dialog box' primary intended purpose is for authentication, and I think we should prioritize that use over other uses like the anti-spam/robot-speedbump use.

* Data about what real sites in the real world use it for would be nice. But I don't know if we have that data. Probably not; we'd have to gather it ourselves by crawling the web and applying a heuristic to determine if the realm string seems robot-speedbump-y or real-authentication-y. (I doubt UMA would be a good mechanism for collecting the realm strings.)

* HtTP Basic Auth usage numbers are very low, in any case. (See UMA histograms Net.HttpAuthCount and Net.HttpAuthTarget).

Comment 24 by, Jan 29 2016

I feel a need to remind folks that the initial report has nothing to do with valid use of basic auth with a realm.  The issue is with a man in the middle or malicious site triggering a challenge.  The realm string offers an opportunity to modify the trusted browser UI to effect social engineering and induce the user to provide credentials against their own interest.

Removing the realm does this but I wouldn't have gone so far.  My original suggestion stands, visually distinguish the untrusted realm string and include text to inform the user this is not trusted.

Edge has a similar vulnerability and I made the same report to Microsoft.

Comment 25 by, Feb 2 2016

I agree that the primary purpose is authentication and it should be prioritized.

I feel like it's *possible* to include untrusted text while making it clear that it's untrusted... but it would take effort. Is it worth that effort, given that it supports an unintended use case (that could be replaced with CAPTCHAs)? Not sure.

Comment 26 by, Mar 9 2016

 Issue 593225  has been merged into this issue.

Comment 27 by, Mar 11 2016

#593700 : in the case of a proxy, website's "trustworthy or verified strings" (url) is displayed instead of proxy's one, this is misleading users (and can conduct them to reveal website's credentials to the proxy) and not really respecting the "trustworthy or verified strings" assomption (as proxy's informations should be displayed here).

Comment 28 by, Mar 15 2016

 Issue 594755  has been merged into this issue.

Comment 29 by, Apr 11 2016

 Issue 602301  has been merged into this issue.

Comment 30 by, Apr 12 2016

I don't see how this change actually fixes the problem or actually realistically prevents the phishing attack in general. Even with the modifications in place, the dialog still looks legitimate because it says that the web site is requesting the username and password. The user doesn't get the prompt that it's their Google account but will still likely provide their credentials anyway. Instead of taking away the realm string from the UI, I feel a more appropriate response would be to permit the domain to flag this as inappropriate similar to HSTS. Then if a MITM attack on an unsecured request occurs the browser can block the response as malicious or retry over a secure channel.

We use the text to provide information like "input your password and two factor token" on the dialog. It's not uncommon for many environments to clarify what sort of password is required for organisations that have multiple authentication directories (universities for example have multiple directories that might not be federated). It'd would be good to get this change rolled back and a more appropriate fix built.

Comment 31 by, Apr 12 2016

Avi, could we look at making these look more like they are part of the page (as has been done for alerts in Safari, and proposed for Chrome alerts)?

Comment 32 by, Apr 12 2016

Re #30: In general, phishing is not a solvable problem and no software fix can prevent it.

What we can do is *mitigate* it, such as by not showing attacker-provided strings (such as the realm string) in trusted/hopefully-trustworthy native chrome (such as the Basic Auth dialog). And by only showing the true web site/origin, in as clear a way as possible, with no other distractions. That is what my fix aims to achieve.

I'm not sure how an HSTS-like solution would work to stop or even mitigate an attack like the following:

1. Browser navigates to a phishing domain like

2. shows a phishy HTTP Basic Auth dialog, with a realm string such as in the original bug report (see above: "Please sign in with your Google account").

How would the browser 'know' to check for a statement of HTTP Basic Auth policy (expressed in an HSTS-like header)?

In any case, other authentication mechanisms (including regular old forms and cookies) are superior to HTTP Basic Auth in several key ways:

* The person can log out without having to end their entire browsing session

* The cookies can expire on their own (the developer can set a cookie expiry)

* The web developer can fully control the UX in the web content (including not having to overload the single Password field for use both as a password and as a 2FA field)

Comment 33 by, Apr 13 2016

Even with the changes in place, the realm string isn't there but if someone goes to and gets a password request, do you really believe they're not going to hand over their GMail credentials?

The thought about something like HSTS is when prompted with an authentication challenge over HTTP to re-attempt it over HTTPS and perhaps get a header that flags that authentication requests should only occur over HTTPS and for the browser to block the request. The browser would need to upgrade the request upon receiving a challenge on HTTP however this would better fix your phishing problem because it would hopefully result in a secure channel being established and the MITM avoided.

I acknowledge the issues with HTTP Basic Auth but that doesn't mean that it shouldn't work the way folk expect in Chromium based browsers. And part of that expectation is that the realm string shows up in the UI somewhere.

Comment 34 by, Apr 19 2016

In response to #32:

> In any case, other authentication mechanisms (including regular old forms and cookies) are superior to HTTP Basic Auth in several key ways:

They have one enornmous disadvantage: they rely on the implementation of the website in question. I don't trust Wordpress', Joomla's and Magento's code base, and a HTTP password is a very good way to prevent that code from even running until you're authenticated, even if only by a bot speed bump.

In response to: #23

> The HTTP Auth dialog box' primary intended purpose is for authentication, and I think we should prioritize that use over other uses like the anti-spam/robot-speedbump use.

In essence I agree, but it's a perfect system. And there is no (good) alternative either. With basic auth, I can just configure Apache (for example) to match all /admin locations on all sites and be done.

Comment 35 by, Apr 20 2016

Re #33: 
> " you really believe they're not going to hand over their GMail credentials?"

What about using a proxy? With the current implementation you just see the URL of the proxy server without further hints what system you are requesting data from. 

We normally use the realm to show the user which backend she uses when a service requests a user/password for a service.
This is now broken (as the users do not know which system is behind which port of the proxy without the additional information in the realm message).

Also the RFC mentions that the realm should be shown to users: 
     A string to be displayed to users so they know which username and
     password to use. This string should contain at least the name of
     the host performing the authentication and might additionally
     indicate the collection of users who might have access. An example
     might be "".

Comment 36 by, May 24 2016

To me it very simple:

I have to log into a bunch of sites all day, with some being sub domains or the others.

I have different credentials for the master domain (my college) compared to my local domain (my department) - and several others for testing.

It is very useful to be reminded which realm I am logging into.

So I believe the realm string should be displayed as the RFC suggests. This is not a matter of how technical users are. I'm technical and I like seeing the realm string. Non technical users can of course ignore it.

Kind regards,


Comment 37 by, May 24 2016

Our concern is that the great majority of people won't know that they can, and should, ignore the realm string.

Comment 38 by, May 25 2016

People also don't know that they shouldn't enter their login data in phishing sites, but we all agree that not displaying websites is not an option.

I've noticed on several places right now (me, and people asking me) how cumbersome the lack of a realm string is. When try to open a page and just gives you a popup with two fields is unhelpful. It saying "Please login with your Active Directory credentials" is really required.

Just a wild idea, but what about not displaying a 90s interface-blocking popup, but instead an in-tab rendered page, with URL bar showing (the lack off) a SSL certificate?

Comment 39 by, May 26 2016

 Issue 614511  has been merged into this issue.

Comment 40 by, May 27 2016

WWW-Authenticate is defined by RFC 2617 and 7235
   These realms allow the protected resources on a server to be
   partitioned into a set of protection spaces, each with its own
   authentication scheme and/or authorization database. The realm value
   is a string, generally assigned by the origin server, which may have
   additional semantics specific to the authentication scheme. Note that
   there may be multiple challenges with the same auth-scheme but
   different realms.
Yes, basic auth is a 1990's construct, but at least now we can log out in e.g. Firefox without quitting. I was using it as a simple captcha that works across virtually all browsers, even text-mode ones without scripting capability, except, it seems, Chrome since around version 30.
10.1 KB View Download
20.5 KB View Download

Comment 41 Deleted

Comment 42 by, Jun 29 2016

Hello my web host uses Auth protection on any wp-admin attempt. Usually it includes the text 

WordPress attack protection CAPTCHA. Enter username: trhfg5 Password: The result of math 16-2

but this information is not seen in Chrome so it is not possible to login directly.

Comment 43 by, Jun 30 2016

For larger and more complex setups, where it is not feasible to modify 3. party web applications to add federated security, or any security for that matter, the usage of HTTP Auth is crucial.
In addition we use API keys, that a developer can use instead of username and password. Information about this is given in the realm description, such that the information is available where required. For instance: "Enter usename or password, or API Key as username and a blank password."
The display of the url that provides the realm seems fine, as long as the realm is displayed as well.

Comment 44 by, Jul 8 2016

 Issue 625937  has been merged into this issue.

Comment 45 by, Aug 9 2016

Hi, I think this is the "lazy way" to solve a really big problem in the world...the usage of AuthName is available in all others navigators, is necessary for the usual uses and for stop the bots, spam and brute force attacks, the most simple and effective way, are created this bug for "fix" a possible pishing ¿? no comment........Regards

Comment 46 by, Aug 30 2016

We use basic authentication with multiple realms and now we have to tell our 4k+ users if they use chrome they will just need to remember what passwords go with what resources as they no longer can get a clue from the dialog box. It has really created a lot of chaos for us, and I feel ridiculous having to tell the most confused users "maybe you should just use Firefox".

I have to agree with so many of the others on this. We've broken a basic part of browser functionality in the name of protecting people from a possible social engineering attack. I'm not sure this was ever the correct answer but if people are hesitant to reverse this what about at least showing realms for just SSL? This mitigates the header injection questions and returns some functionality.

We seem to be shooting flies with cannons.

Comment 47 by, Sep 5 2016

Re-assigning to felt for now to see if any changes needed over existing behavior.

Comment 48 by, Sep 9 2016

Labels: -Pri-2 Pri-3
Owner: ----
Status: Available (was: Started)
Based on the feedback, sounds like we should add website-controlled strings back in...  but we would need to do it in a way that makes it clear the text is not coming from Chrome.

However, this seems really low priority to me compared to our other open bugs and ongoing work. So I don't expect to see this assigned an owner in the immediate future.

Comment 49 by, Oct 6 2016

Firefox makes it clear where the text is coming from. After the site name, it adds: The site says: "blah blah"

Web site developers took the time to add AuthName text, to help their customers and users, because a site can require different names, in different places. Chrome has taken away a very visible feature.

Comment 50 by, Nov 7 2016

any date for a fix.

Comment 51 by, Nov 7 2016

Just wanted to emphasize it is not possible to log in to e.g. a standard implementation of WordPress with Chrome. Yesterday I told my wife "Use some other browser. Chrome does not work. It is broken."

Comment 52 by, Nov 22 2016

+1 for adding message again to logon dialog:

We have different sites in intranet:

WWW-Authenticate: Basic realm="Requires windows password (LDAP)"
WWW-Authenticate: Basic realm="Requires RACF password"

Comment 53 by, Nov 22 2016

Labels: Team-Security-UX

Comment 54 by, Nov 22 2016

Components: -Security>UX

Comment 55 by, Jan 6 2017

Status: Assigned (was: Available)

Comment 56 by, Jan 6 2017

 Issue 606392  has been merged into this issue.

Comment 57 by, Mar 11 2017

 Issue 700538  has been merged into this issue.

Comment 58 by, Mar 13 2017

Thanks for the update.

Any ETA for the fix?


From: asa… via monorail []
Sent: Saturday, March 11, 2017 9:06 AM
To: Raj, Lourdu <>
Subject: Issue 544244 in chromium: HTTP basic auth credentials prompt should make the origin stand out more

Comment 59 by, Mar 13 2017


Comment 60 Deleted

Comment 61 by, Mar 22 2017

I would also like to know an update on this. htpasswd is the only real way now to stop dos attacks against wp-login scripts and the random challenge prompt that is supposed to be displayed does NOT show up in chrome making it impossible for real users to know what the login is.

Comment 62 by, Mar 22 2017

I'll look at this soon, but am currently working on a higher priority bug, so I can't promise that it will make it to M59. If anyone else wants to take over, please feel free.

We should explore if there is something better we could do than simply putting back the message. For example, we could hide the untrusted string if the dialog is initiated by a cross-origin resource. I also noticed that Safari and Opera also don't show the realm string.

Comment 63 by, Mar 22 2017

thanks!, yea they don't show it either, but in terms of % browser usage, I can live with those browsers not working :) but chrome is almost 50% of the browser share.

also the cross origin resource limitation am I assuming would not work for a server wide htpasswd set rule would it? that is what I have implemented to affect all sites on my server? or because its still coming from my server natively that would not be an issue.

also why not just roll back to displaying the way it was until a better method can be figured out? 

I also agree this does nothing to stop a user who doesn't know better to enter their login credentials on any phish site asking for it regardless of the way its asked.

not a programmer myself otherwise id jump in :)

thanks for your input.

Comment 64 by, Jul 7 2017

Simply removing the realm was the wrong way to solve this issue. Please stop breaking the Internet and come up with a better solution to address the valid concern that this bug report raises.

Comment 65 by, Aug 30 2017

On the phishing concerns: If someone can inject an authentication header, they can at least redirect the user to a legitimate-looking page or just present an HTML login form to collect credentials. This has no additional indication that the entire page is untrusted information, other than the address bar. (Users might be more likely to trust HTML login forms, since they are used to seeing them)

Showing something similar to the black text part of the address bar (hostname) with the "Secure" or "Non-secure" seems to offer the same protection for Basic auth as for HTML login forms. (I also like #38)

(My use of Basic auth is on Intranet pages, where the realm gives instructions on which username to use and informs the user of username case-sensitivity. E.g. "User your Windows password in lower-case, no 'DOMAIN\', just name.surname")

Comment 66 by, Oct 11 2017

Any update on this?

Comment 67 by, Oct 26 2017

This is a real problem for my team. Basic auth is how my company implements 2 factor authentication where needed. Since Chrome won't show a custom message, end users don't realize they are being prompted for a special pass code instead of their normal username and password. So they keep entering their username and password thinking they must be fat-fingering it, only to end up locking themselves out of their account.

Comment 68 by, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 69 by, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Comment 70 by, Jun 9 2018

Please fix this issue.  I've been keeping an eye on this bug for years now but it seems to be going nowhere and it is certainly not getting the attention it deserves.  

As #23 expressed, the number of people that are being affected in a negative manner by this bug is not known.  I'm here to shed some light on at least some of those numbers and to share how it is causing a negative perception of the Chrome browser because of it.

I also agree with #64 and the other comments regarding phishing attacks in general.  Something was broken in Chrome that has worked in most all browsers for decades (and Chrome itself up to this point) which is relied upon to effectively combat several different abuse problems and fulfills many real-world usage scenarios because it was felt that Chrome should behave differently for certain users (seemingly your average casual user in the interest of preventing possible phishing attacks and their view that the custom Auth dialog string was coming from the browser itself because it was in a dialog box and therefore apparently legitimized).

Other comments address most of this, I am here because of the expressed interest in getting some metrics on how many people this is affecting.  For just the companies I am directly involved with, it is affecting upwards of fifty-thousand users for almost three years now.

Two of the companies with public facing Webmail, Wordpress, and other software running on them have FAQ's which mention Chrome as broken for this functionality and contain instructions on how to work around what the users are trying to do (ie: which set of credentials to use) depending on what they are trying to access if they are specifically using Chrome.

There is a large hosting company that serves Windows users run by a colleague of mine which has a similar dedicated page in their trouble ticket system referring to this (and specifically to this thread).

Several IT programmers I know in corporate environments (from Intel to smaller in-house network admins) are aware of this issue and offer the advice to avoid Chrome in their Intranet or in-house environments to everyone from the business owners and project leads down to the users.

I am highly confident that these user numbers are only a small part of the overall number of people this bug is affecting and their perception of the Chrome browser.

Just tested on Chrome 'Version 67.0.3396.79 (Official Build) (64-bit)' and it is still broken as of 06/09/2018.

Comment 71 by, Jun 11 2018

It could at least be shown for HTTPS websites.

Comment 72 by, Jun 25 2018

We're also facing this issue. This realm is the only way to displays an information message helping the user to authenticate.

Some of our users (actually a significative percentage; something like 20-30%) are kinda lost, wondering if they should use their email or their login, and what password they should use. Being in doubt those users reach the support team (and so consume our time and money) because Chrome doesn't want to show the realm.

Is there a chance that would change ?

Comment 73 by, Oct 19

Hi guys, 

We're also facing an issue regarding Realm for Chrome Version 67.0.3396.99 (Official Build) (64-bit). We're sending a request to Facebook to authenticate, but this is not recognized. We're using the AuthType Basic in our .htaccess.

Hoping this will get the attention. I'm looking forward for an update.

Kind regards,

Sign in to add a comment