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>;
anyway, the fix is easy. just use firefox, again. it's actually pretty fast 'n all now ;-)
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".
$ curl -vv 'http://username:password@example.com/
> GET / HTTP/1.1
> Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
dXNlcm5hbWU6cGFzc3dvcmQ= is base64 encoded 'username:password'
The Authorization header is the same one that will be used if your browser prompts you for a username/password.
Also, the Authorization header is also plain text. Whether you pass credentials on the URL or in the Authorization header, it makes little difference in terms of interceptability. They're just different lines in the HTTP request. You need SSL to secure either.
That said, the most common argument that I heard against supporting this stuff is phishing, using the credentials part to push the real address as far as possible to the right/off the screen.
I - don't like that decision. I have basic auth services in internal networks and would like to access them this way.
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.
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.
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.
The phishing attack occures when you look at the URl before clicking on it.
http://www.microsoft.com:getwindowsforyourcomputer.etc@evils... looks safe for civilians.
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
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.
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.
I would be curious to know who actually uses this type of auth in their browsers these days.
