I've noticed many times the browser won't send those from the link. I was trying that with services where I owned both sides and my pre-authenticated links weren't sending the credentials. But using the same URL via curl was authenticated.
The concern is about phishing via URL spoofing. For example, a user might see a URL like `google.com@mycoolphishingsite.se` and believe that "google.com" is the domain. The warning is intended to point out that "mycoolphishingsite.se" is the real domain.
Over HTTPS? I don't see how that's possible unless they are TLS-MITM proxies, in which case you've completely lost regardless of your authentication method.
Placing the username and password in the URL results in the same TLS-protected HTTP header as normal basic authentication:
Even over HTTP, a proxy that intentionally logs the URL accessed would not see the username and password in the initial "GET" line. It would have to go out of its way to extract it from the Authorization header, which is still present regardless of how the basic authentication was initiated.
If you meant user agents logging the username and password as part of the history, I suppose you could consider that a bug but it could also be considered a feature. Presumably if you're using a URL of that form your intent is in fact to be able to link or bookmark the URL including the credentials.
Layer 7 proxies like Cloudflare can read the headers but there seems to be some mix up between API keys sent in URLs and basic auth. The old arguments against it are potential leaks when no encryption is used, credentials sent on each request and the problem with sessions and logouts. You cannot really logout a user.
Comments
If this is new to you, you can also include the username and password in the url:
https://user@example.com/page
https://user:pass@example.com/page
I've noticed many times the browser won't send those from the link. I was trying that with services where I owned both sides and my pre-authenticated links weren't sending the credentials. But using the same URL via curl was authenticated.
On Firefox, I just get a warning: "You are about to log in to the site “news.ycombinator.com” with the username “test”"
I'm not entirely sure what the concern is to be honest. If it's tracking, this doesn't provide anything on top of query parameters e.g. ?utm_campaign=
The concern is about phishing via URL spoofing. For example, a user might see a URL like `google.com@mycoolphishingsite.se` and believe that "google.com" is the domain. The warning is intended to point out that "mycoolphishingsite.se" is the real domain.
I believe the major browsers deprecated this a little while ago. You can still use basic auth and everything, just not via a URL like this.
The problem is that many proxies will log passwords sent this way.
Over HTTPS? I don't see how that's possible unless they are TLS-MITM proxies, in which case you've completely lost regardless of your authentication method.
Placing the username and password in the URL results in the same TLS-protected HTTP header as normal basic authentication:
Even over HTTP, a proxy that intentionally logs the URL accessed would not see the username and password in the initial "GET" line. It would have to go out of its way to extract it from the Authorization header, which is still present regardless of how the basic authentication was initiated.If you meant user agents logging the username and password as part of the history, I suppose you could consider that a bug but it could also be considered a feature. Presumably if you're using a URL of that form your intent is in fact to be able to link or bookmark the URL including the credentials.
Layer 7 proxies like Cloudflare can read the headers but there seems to be some mix up between API keys sent in URLs and basic auth. The old arguments against it are potential leaks when no encryption is used, credentials sent on each request and the problem with sessions and logouts. You cannot really logout a user.
Corporate proxies often need to log every URL that is visited. It's mostly used as a defense against employees looking at porn on the job.
And corporate proxies man in the middle everyone, because the entity that controls the proxy also controls the certificate on the computer.