Project: chromium Issues People Development process History Sign in
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 58 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
HTTP basic auth credentials prompt should make the origin stand out more
Reported by rshu...@gmail.com, Oct 16 2015 Back to list
Steps to reproduce the problem:
   Here is what I see when visiting www.YouTube.com on a Nexus 7 running Android 5.1.1 with a man in the middle injecting a WWW-Authenticate header.

Rich

From: security@google.com
Sent: Friday, October 16, 2015 8:37 AM
To: rshupak@gmail.com
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.
Cheers,
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:
None

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 och...@chromium.org, Oct 16 2015
 Issue 544240  has been merged into this issue.
Comment 2 by meacer@chromium.org, 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 (http://m.youtube.com:80). 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 och...@chromium.org, Oct 16 2015
Labels: -Restrict-View-SecurityTeam -Type-Bug-Security Cr-Security-UX Type-Feature
Comment 4 by meacer@chromium.org, Oct 16 2015
Cc: palmer@chromium.org
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 rshu...@gmail.com, 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 rshu...@gmail.com, 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 meacer@chromium.org, 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 rshu...@gmail.com, Oct 16 2015
This is not an HTTP vs. HTTPS issue.

See attached landscape screenshot where address bar is obscured.
Screenshot_2015-10-16-13-32-28.png
112 KB View Download
Comment 9 by meacer@chromium.org, 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 rshu...@gmail.com, 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.
Filed  bug 544272  for the keyboard issue.
And duped it into bug 544267.
Cc: -palmer@chromium.org f...@chromium.org
Labels: Cr-Internals-Network-Auth Cr-UI-Auth
Owner: palmer@chromium.org
Status: Assigned
@palmer: I have a CL at https://codereview.chromium.org/1415243004/ 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 rshu...@gmail.com, 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.
The realm is already separated from the top text, grayed out, and wrapped in quotes in the screenshot: https://drive.google.com/a/google.com/file/d/0B9q2eN9gDoUIVG5ETExTeDRlWFk/view

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@.
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.
edge-basic-auth.png
22.2 KB View Download
ff-basic-auth.png
49.7 KB View Download
CL in progress at https://codereview.chromium.org/1466473003/. 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
Here are the Android screenshots.
Screenshot_20151123-160911.png
104 KB View Download
Screenshot_20151123-160918.png
109 KB View Download
Project Member Comment 20 by bugdroid1@chromium.org, Dec 8 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d4fe8211476a0bba1a347204e430aa283c2e7d7f

commit d4fe8211476a0bba1a347204e430aa283c2e7d7f
Author: palmer <palmer@chromium.org>
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.

BUG=544244

Review URL: https://codereview.chromium.org/1466473003

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

[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/app/generated_resources.grd
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/app/nibs/HttpAuthLoginSheet.xib
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/android/chrome_http_auth_handler.cc
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/android/chrome_http_auth_handler.h
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/android/login_prompt_android.cc
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/cocoa/login_prompt_cocoa.h
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/cocoa/login_prompt_cocoa.mm
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/login/login_prompt.cc
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/login/login_prompt.h
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/views/login_prompt_views.cc
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/views/login_view.cc
[modify] http://crrev.com/d4fe8211476a0bba1a347204e430aa283c2e7d7f/chrome/browser/ui/views/login_view.h

Status: Fixed
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”).
Cc: asanka@chromium.org egm@chromium.org cbentzel@chromium.org est...@chromium.org
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 rshu...@gmail.com, 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 f...@chromium.org, 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.
 Issue 593225  has been merged into this issue.
#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).
Cc: palmer@chromium.org
 Issue 594755  has been merged into this issue.
 Issue 602301  has been merged into this issue.
Comment 30 by pasa...@gmail.com, 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.
Cc: a...@chromium.org
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)?
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 gmai1.com

2. gmai1.com 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 https://mail.google.com 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 pasa...@gmail.com, Apr 13 2016
Even with the changes in place, the realm string isn't there but if someone goes to http://gmail.com 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 wi...@ytec.nl, 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.
Re #33: 
> "...do 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: 
realm
     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 "registered_users@gotham.news.com".
Source: https://tools.ietf.org/html/rfc2617#section-3.2.1
Comment 36 by t...@dionic.net, 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,

Tim
Our concern is that the great majority of people won't know that they can, and should, ignore the realm string.
Comment 38 by wi...@ytec.nl, 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? 

 Issue 614511  has been merged into this issue.
Comment 40 by ad...@triumf.ca, May 27 2016
WWW-Authenticate is defined by RFC 2617 and 7235
quote:
   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.

login1.png
10.1 KB View Download
Screenshot-52.png
20.5 KB View Download
Comment 41 Deleted
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 jor...@veridit.no, 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.

Cc: a...@chromium.org
 Issue 625937  has been merged into this issue.
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, and...you are created this bug for "fix" a possible pishing ¿? no comment........Regards
Comment 46 by ltow...@gmail.com, 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.

Owner: f...@chromium.org
Re-assigning to felt for now to see if any changes needed over existing behavior.
Comment 48 by f...@chromium.org, Sep 9 2016
Cc: -egm@chromium.org meacer@chromium.org
Labels: -Pri-2 Pri-3
Owner: ----
Status: Available
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.
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 teic...@gmail.com, Nov 7 2016
any date for a fix.
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."
+1 for adding message again to logon dialog:

We have different sites in intranet:

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




Labels: Team-Security-UX
Components: -Security>UX
Owner: meacer@chromium.org
Status: Assigned
Cc: lgar...@chromium.org
 Issue 606392  has been merged into this issue.
Cc: mzheng@chromium.org blumberg@chromium.org ligim...@chromium.org
 Issue 700538  has been merged into this issue.
Comment 58 by l...@ebay.com, Mar 13 2017
Thanks for the update.

Any ETA for the fix?

Thanks.

From: asa… via monorail [mailto:monorail+v2.2202578363@chromium.org]
Sent: Saturday, March 11, 2017 9:06 AM
To: Raj, Lourdu <lraj@ebay.com>
Subject: Issue 544244 in chromium: HTTP basic auth credentials prompt should make the origin stand out more
Cc: -palmer@chromium.org
Comment 60 Deleted
Comment 61 by john...@gmail.com, 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.
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 john...@gmail.com, 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.
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.
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")
Any update on this?
Sign in to add a comment