
Chrome 19 doesn't respect basic auth details embedded in the URL - ansman
http://code.google.com/p/chromium/issues/detail?id=123150
======
michiel3
This technique is widely abused by phishers. Most browsers detect such
phishing attacks and warn the user for it (see example in Safari 5).

Firefox might do a better job on this subject: it performs a HEAD request
first, to see if the website actually requires authentication. If not, the
user receives a warning to make the user aware of a potential phishing attack
they might have been trapped into.

~~~
Nitramp
That could be easily spoofed by requiring just some username on the server
side, assuming you set up your web presence such that these links always
include some username. The HEAD request won't help you there.

~~~
michiel3
This won't help that much, because this means you can only visit the website
with some authentication string, otherwise the browser will prompt for your
credentials.

------
djpowell
HTTP URIs never officially supported this syntax anyway:
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2)

The userinfo component is supported according to the URI generic syntax, which
FTP URIs follow, but HTTP URIs don't. See the sadly still not obsolete
RFC1738: <http://tools.ietf.org/html/rfc1738#section-3.1>

~~~
__alexs
RFC 2616 also says "For definitive information on URL syntax and semantics,
see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC
2396" and it is frequently documented on the interwebs that HTTP uses the
generic URI syntax.

I'm not trying to suggest that the intent of the RFC was to allow <authority>
where it says <host> in 3.2.2 but I can see how this wording might be
confusing, especially when taken with historically observed UA behaviour.

------
avbor
<http://support.microsoft.com/kb/834489>

I remember reading about Microsoft stopping supporting that option actually.
The reasoning being that it could be used for sending users to malicious
sites.

"malicious users can use this URL syntax together with other methods to create
a link to a deceptive (spoofed) Web site that displays the URL to a legitimate
Web site in the Status bar, Address bar, and Title bar of all versions of
Internet Explorer."

I'm wondering if this was the reasoning for doing so in Chrome.

~~~
Dylan16807
That's a ridiculous reason. The most recent version of IE that supports the
syntax already hides the username:pass to completely solve this problem.

Opera does the same thing.

Firefox asks if I want to log in then does the same thing.

The pre-change version of chrome I have does the same thing.

~~~
nl
It's not a ridiculous reason at all.

The phishing attack occures when you look at the URl _before_ clicking on it.

[http://www.microsoft.com:getwindowsforyourcomputer.etc@evils...](http://www.microsoft.com:getwindowsforyourcomputer.etc@evilsite.com/)
looks safe for civilians.

~~~
piotrSikora
...and how is that different from

    
    
        <a href="http://evilsite.com">microsoft.com</a>
    
    ?

~~~
sirclueless
It looks different in the status bar, which is the important bit.

~~~
piotrSikora
Like Dylan16807 said - it doesn't. Chrome already hides "user:pass" bits in
the status bar.

------
dirkdk
I get it if Chrome developers want to stop spoofing of malicious urls like
<http://veryfamouswebsite.com:pwd@malicioussite.com>. However, I prefer the
Firefox way: FF prompts you if you want to login with the username specified
in the url.

~~~
Nitramp
That's cool, but how many users will understand what's being asked for? If the
user says yes (and users will always just click the "go on do it" button),
they basically agreed to being tracked indefinitely :-(

~~~
dirkdk
it is not so much about tracking, more about directing somebody to a web site
they did not intend to visit

------
badboy
Wow, BasicAuth is quite unusable these days. Disallowing BasicAuth in typed-in
urls is just one side. The other thing is that I can't use BasicAuth to
download files on Android[1] (and that bug is 4 years old)

[1]: <http://code.google.com/p/android/issues/detail?id=1353>

~~~
mike-cardwell
<http://www.123-reg.co.uk/> is a pretty big domain management company and they
still use basic auth. I actually don't think users care. It _looks_ a bit
shoddy, but it works fine. Most people care more about the price of the
product than how the site manages authentication.

~~~
nicholassmith
I think that's a bad example to hold up, there's a repeatable issue with
123-reg's basic auth system that stops you from being able to fully log out on
certain platforms.

~~~
mike-cardwell
Basic auth has no logout feature as far as I understand it. 123-reg tries to
hack on something which looks like a logout feature but isn't.

For the point I was trying to make, it was the _perfect_ example. It
demonstrates that you can use basic auth, have "working" authentication, and
be a successful website.

Note, the comment I was replying to was that basic auth is "unusable". 123-reg
clearly disproves this.

~~~
colanderman
Why can't basic auth logout be handled by the browser? e.g. display a "logout"
button on the navigation bar when you're logged in with basic auth?

~~~
mike-cardwell
I guess it could be. If the browser vendors implemented such a feature.

------
spauka
While I understand their concern, it is none the less quite a useful feature
for testing.

Firefox warns users if they are authenticating to a site with a small message
and asks them to confirm. This prevents pretty much all of the phishing
attacks that people have been talking about without removing a potentially
useful feature.

------
samvj
I think it's worth mentioning that "IE 7/8/9: OK" is not correct according to
this: <http://support.microsoft.com/kb/834489>

I would be curious to know who actually uses this type of auth in their
browsers these days.

------
tluyben2
Ah! In many company (I have seen it in huge and tiny companies) this will
break their SSO 'systems' :) Intranet pages covered with links to internal
systems like this are rather normal.

~~~
RDeckard
Don't they still use IE6 in these companies anyway? :)

~~~
eli
It's gotten much better in the last 18 months. But yeah there are still some.

------
afhof
This may be slightly OT but having the auth in the url has some benefits when
using a handler for certain file types. The Android Browser violates this if
you go to a site requires auth and then links to video/audio. When the media
player is passed the url, the credentials are lost and the media fails to
play.

~~~
badboy
That's not only the case for media files but for everything you try to
download via the included download manager. And that sucks pretty much.

------
napolux
To me is just a security feature. IN ANY CASE you should not provide
credentials via URL.

------
adamkhrona
This is good: it's totally insecure to pass auth credentials in plain-text
URLs.

~~~
vivekjishtu
What if I send it over https <https://foo:bar@dump.ansman.se/basic-auth/foo>?
I don't think it should be insecure in this case.

~~~
sausagefeet
I think the concern is making the user look like another URL you trust.

------
zerostar07
Not nice of google to try to change the ways of the web without prior
discussion. Some people may store these URLs in bookmarks for convenience.
What's next? disallow the javascript: protocol maybe?

------
uptown
Since Chrome's addressbar functions as both a search input and an address bar,
is it possible they're doing this to prevent usernames and passwords from
being continually added to Google's search history logs? I see both sides of
the argument for allowing or removing this functionality ... but the fact that
user input from the omnibar is passed along to Google in real-time changes
things and potentially opens up Google to receiving usernames and passwords to
sites they have no business having access to.

------
alexknight
Based on the potential security/privacy implications of supporting this, I
think Google did the right thing by deprecating this.

------
jsprinkles
Reason for this everybody is overlooking:

Usernames and passwords can be added to links to resources (and images) which
aren't necessarily protected by authorization, and in that sense can be used
as a "cookie" of sorts to track users irrespective of cookie settings. It's a
bit hokey, but I've heard of it being done before (more than once, actually).
Try it on your Web server, and dump the headers for your image request after
you serve this:

<img
src="[http://cookiedata@example.com/image.gif>](http://cookiedata@example.com/image.gif>);

~~~
__alexs
OK that seems like the sort of situation you'd want some sort of privacy
controls in but this bug is about it getting ignored when you type it into the
URL bar yourself right?

~~~
moe
The ipad browser pops up a red phishing warning when you access a bookmark(!)
that has credentials in the URL.

This is royally annoying because the same browser can't save these credentials
otherwise.

So for sites using simple/digest-auth you're given the choice between typing
in your password every time, or getting that stupid warning dialog every time.

Good work, Apple. That is truly "magical".

