4 ms·

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

vivekjishtu 14y ago
What if I send it over https https://foo:bar@dump.ansman.se/basic-auth/foo https://foo:bar@dump.ansman.se/basic-auth/foo? I don't think it should be insecure in this case.
- deleted 14y ago
  [deleted]
  - sern 14y ago
    This is incorrect. https encrypts everything.
  - skeletonjelly 14y ago
    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.
    - chris_wot 14y ago
      RFC 2818 says the following: 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 :-)
  - dudus 14y ago
    Compression is done only on the body not on the headers. But HTTPS encryption is done in the whole connection.
  - drivebyacct2 14y ago
    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.
- sausagefeet 14y ago
  I think the concern is making the user look like another URL you trust.
benjiweber 14y ago
They're not passed in the URL. Try it yourself: $ curl -vv 'http://username:password@example.com/ 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.
darklajid 14y ago
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 https://foo:bar@dump.ansman.se/basic-auth/foo? I don't think it should be insecure in this case.

deleted 14y ago
[deleted]
- sern 14y ago
  This is incorrect. https encrypts everything.
- skeletonjelly 14y ago
  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.
  - chris_wot 14y ago
    RFC 2818 says the following: 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 :-)
- dudus 14y ago
  Compression is done only on the body not on the headers. But HTTPS encryption is done in the whole connection.
- drivebyacct2 14y ago
  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.
sausagefeet 14y ago
I think the concern is making the user look like another URL you trust.

benjiweber 14y ago

They're not passed in the URL. Try it yourself: $ curl -vv 'http://username:password@example.com/ 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.

darklajid 14y ago

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.