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.
Well, basic auth is plaintext over the wire anyway. I don't think that you lose that much 'security' by putting them into the url.
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.
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
precisely as you would use HTTP over TCP.
TLS is meant to be transparent to the higher level protocol - in other words, independent of HTTP. The headers should be encrypted also.
For a long time, I also believed that the URL would not be encrypted (e.g. GET /example/url.htm), but as it's running as a transparent connection then this is also encrypted. I had to check this to see if GET requests with session IDs would be vulnerable over the wire - I was quite relieved when I realised my assumptions were wrong! Also meant I had to read a few specs :-)
As an aside, everyone has blidnspots and continuing to downvote howardr does nothing but make you feel better about yourself. This bloke's total karma is down to '2' and I'm betting it's much higher than that minus this post.
Comments
This is good: it's totally insecure to pass auth credentials in plain-text URLs.
They're not passed in the URL. Try it yourself:
$ 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.
Well, basic auth is plaintext over the wire anyway. I don't think that you lose that much 'security' by putting them into the url.
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.
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.
I think the concern is making the user look like another URL you trust.
[deleted]
This is incorrect. https encrypts everything.
Compression is done only on the body not on the headers. But HTTPS encryption is done in the whole connection.
Are you sure? I just did a quick test with Fiddler and didn't see the credentials there. I only see them when I enable HTTPS decryption.
RFC 2818 says the following:
TLS is meant to be transparent to the higher level protocol - in other words, independent of HTTP. The headers should be encrypted also.For a long time, I also believed that the URL would not be encrypted (e.g. GET /example/url.htm), but as it's running as a transparent connection then this is also encrypted. I had to check this to see if GET requests with session IDs would be vulnerable over the wire - I was quite relieved when I realised my assumptions were wrong! Also meant I had to read a few specs :-)
As an aside, everyone has blidnspots and continuing to downvote howardr does nothing but make you feel better about yourself. This bloke's total karma is down to '2' and I'm betting it's much higher than that minus this post.