TLS to secure Basic HTTP Auth

Question

Basic Auth, including Bearer tokens, depend on using TLS to prevent eavesdroppers from getting at your sensitive credentials or tokens. But I think there is an Elephant in the room that nobody talks about.

Users often only type in "www.somesite.com" in stead of "https://www.somesite.com". AFAIK when you don't specify the protocol, the client browser will first try the default, un-encrypted HTTP connection.

The problem is that the user is basically asking for an un-encrypted connection to be made to the server because that's the default when no protocol is specified. The browser could potentially include sensitive information in the request headers, including Basic Auth credentials, Tokens, (and even Cookies that are not set "Secure")

For API clients that send tokens the situation is similar, but partially mitigated by hopefully well written client applications that

1. Actually use only the SSL encrypted port to connect to, and
2. The Developer actually turned the "Check the SSL certificate" option on before he published their app.

I'm of a mind to set up a MITM proxy on my home network to start checking and logging the apps that I use. In particular I want to spoof some DNS records and see whether the apps actually baulk at sending your credentials/tokens to the wrong server.

I personally would have preferred JWT to be specified as being sent in a SECURE cookie only, rather than in the headers... Does anybody here think my concern is not warranted?

EDIT: To clarify: I'm not so much worried by the weakness of SSL or attacks against DNS, I am more worried about credentials being exposed because clients end up sending it over unencrypted connections in any case, whether due to user's bad behaviour or because the client just follows redirects to SSL ports but only after sending the user's credentials. When designing APIs I will from now on add a listener on the unencrypted port. If it receives any token on that port, it will

1. Not Redirect, and
2. invalidate the credentials, and
3. send the user a warning.

Hopefully developers who write apps that consume these APIs will get the hint. Would blacklisting the IP for a few hours be too harsh?

P.S. Note: With Secure cookies we still depend on the browser being correctly implemented.

Answer 1

the client browser will first try the default, un-encrypted HTTP connection, potentially including your Authorization header if the browser has got this details.

I think this assumption is wrong: The browser distinguishes between http:// and https://, i.e. credentials entered on https:// will not be included when accessing http:// and vice versa. This means the browser will only include the credentials for basic authentication on http:// if the user has entered the credentials before on http://. And the browser only asked for the credentials on http:// if the server issued a 401 (authentication required) on http://. If the server instead simply redirects to https:// and only issues the 401 there then the browser will never ask for the credentials on http:// and thus not store the credentials for http:// and not include the credentials on http://.

Answer 2

Any token-based auth has a problem with MiTM attacks. The token standards do not include any mechanism to prevent them.

That means that every app needs to take this into account. You can reduce the risk by keeping token lifetimes very short or you can add a server-side mechanism to track whether the token is coming from the original client.

In this way, virtually all of the token auth examples you see are wrong. Or at least missing this crucial detail.

So yes, in general you are absolutely correct.

Answer 3

First off, HTTP Basic Authentication and REST are both Stateless. Meaning - it is solely up to the Client to manage the session. Unless used for Server to Server communication, using HTTP Basic Authentication with REST is just a Bad Combo. I'd suggest changing your authentication method. refer the Authentication Section in the Accepted Answer here

For Addressing the Username/Password leak, my suggestion will be to:

• have the API Service running separately at https://api.somesite.com (http://api.somesite.com is not accessible)

• have a JavaScript(or your favorite script) API Client embedded in the Webpage(http://www.somesite.com) so that the API Client connects to (https://api.somesite.com) to make the API connection instead of the browser.