HTTP Basic Authentication credentials passed in URL and encryption

Question

I have a question about HTTPS and HTTP Authentication credentials.

Suppose I secure a URL with HTTP Authentication:

<Directory /var/www/webcallback>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/passwd/passwords
Require user gooduser
</Directory>

I then access that URL from a remote system via HTTPS, passing the credentials in the URL:

https://gooduser:[email protected]/webcallback?foo=bar

Will the username and password be automatically SSL encrypted? Is the same true for GETs and POSTs? I'm having a hard time locating a credible source with this information.

Purl

Related: Username and password in https url – Roley

Very old question but nevertheless: this approach has been deprecated by ietf.org/rfc/rfc3986.txt: "Use of the format "user:password" in the userinfo field is deprecated." – Omnidirectional

Answer 1

Will the username and password be automatically SSL encrypted? Is the same true for GETs and POSTs

Yes, yes yes.

The entire communication (save for the DNS lookup if the IP for the hostname isn't already cached) is encrypted when SSL is in use.

Mastic

+1. GETs and POSTs, including the url, are encrypted. I'll only add - tools like firebug and Tamper data are able to show the un-encrypted results only because they are a part of the browser and hence are able to intercept the request before it is encrypted. Once sent over the wire, everything is encrypted. – Itching

To be clear, everything but the domain is encrypted. If anyone stumbles across this and would like a more detailed answer, see answers.google.com/answers/threadview/id/758002.html – Purl

For sake of completeness, "Internet Explorer does not support user names and passwords in Web site addresses (HTTP or HTTPS URLs)" Looks like only Internet Explorer versions 3.0 to 6.0 support the following syntax for HTTP or HTTPS URLs: http(s)://username:password@server/resource.ext Note: This change in the default behavior does not affect other protocols. For example, you can still include user information in an FTP URL after you install the 832894 security update. – Ritchey

Answer 2

Yes, it will be encrypted.

You'll understand it if you simply check what happens behind the scenes.

1. The browser or application will first break down the URL and try to get the IP of the host using a DNS Query. ie: A DNS request will be made to find the IP address of the domain (www.example.com). Please note that no other information will be sent via this request.
2. The browser or application will initiate a SSL connection with the IP address received from the DNS request. Certificates will be exchanged and this happens at the transport level. No application level information will be transferred at this point. Remember that the Basic authentication is part of HTTP and HTTP is an application level protocol. Not a transport layer task.
3. After establishing the SSL connection, now the necessary data will be passed to the server. ie: The path or the URL, the parameters and basic authentication username and password.

Helotry

Answer 3

Not necessarily true. It will be encrypted on the wire however it still lands in the logs plain text

Shaer

What Web server logs the username and passwords from requests? That would be one hell of an insecure web server. – Fionafionna

Yeah this is just not true. It's probably possible to instruct apache to log this information, but it is certainly not doing so by default. – Flournoy

@Shaer was probably thinking "in URL" meant in the query string (eg, ?user=bob&pw=123hackmeplz) . That could end up in the server logs. – Zakarias

Related: "When you call that URL on the client with e.g. curl, the username and password will be clearly visible on the process list and might turn up in the bash history file." - stackoverflow.com/a/4981309 – Roley

This answer is a very important tip for the op. You should never pass credentials in URL because the credentials might end up in some logs. So even if it's not an answer to the original question I'm giving an UPVOTE. – Incivility

Yes I agree with @SzymonWygnański I also gave an UPVOTE – Childhood