Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://security.stackexchange.com/questions/988/is-basic-auth-secure-if-done-over-https below:

tls - Is BASIC-Auth secure if done over HTTPS?

I'm making a REST-API and it's straight forward to do BASIC auth login. Then let HTTPS secure the connection so the password is protected when the api is used.

Can this be considered secure?

65.9k2525 gold badges188188 silver badges227227 bronze badges

asked Dec 5, 2010 at 22:42

4,70333 gold badges1717 silver badges77 bronze badges

There are a few issues with HTTP Basic Auth:

• The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).
• The password is sent repeatedly, for each request. (Larger attack window)
• The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).
• The password may be stored permanently in the browser, if the user requests. (Same as previous point, in addition might be stolen by another user on a shared machine).

Of those, using SSL only solves the first. And even with that, SSL only protects until the webserver - any internal routing, server logging, etc, will see the plaintext password.

So, as with anything it's important to look at the whole picture.

Does HTTPS protect the password in transit? Yes.

Is that enough? Usually, no. (I want to say, always no - but it really depends on what your site is and how secure it needs to be.)

9,1891111 gold badges4646 silver badges6363 bronze badges

answered Dec 5, 2010 at 23:18

73.8k2525 gold badges143143 silver badges223223 bronze badges

Try to think of it this way: When you are logging in to any website using SSL, you are most likely passing password in plain-text over HTTPS (for eg GMail).

The only difference that Basic-Auth makes is that username/password is passed in the request headers instead of the request body (GET/POST).

As such, using basic-auth+https is no less or more secure than a form based authentication over HTTPS.

answered Jul 15, 2012 at 3:27

1,78511 gold badge1414 silver badges1111 bronze badges

Basic Auth over HTTPS is good, but it's not completely safe. Similar to how Fiddler works for SSL debugging, a corporate HTTPS proxy is managing the connection between the web browser and the Proxy (whose IP address appears in your webserver logs). In that case the HTTPS password is decrypted, and later re-encrypted at the corporate proxy.

Depending on who is managing the proxy, and how its logs are used, this may be acceptable or a bad thing from your perspective.

For more information on how SSL interception is done, see this link:

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store.

The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...

Some companies get around the certificate pop-up issue mentioned above by deploying the root certificates (of the Proxy) to each workstation via GPO. Although this will only affect software that uses the Microsoft Certificate store. Software such as Firefox needs to be updated differently.

answered Dec 6, 2010 at 5:49

51.2k5959 gold badges272272 silver badges566566 bronze badges

You note the need for authenticating the client and ask about the security of HTTP basic auth, over SSL. This is what SSL was designed for and will work fine so long as the password is a good one. If you're really setting this up for just a single client, that is easy to ensure by picking a long random password, e.g. 12 characters using a good source of randomness, or other techniques discussed at this site.

Your client also does need to ensure that you have the right cert for the server. In the situation like what you describe, using a self-signed cert as described at the python ssl page referenced will be fine.

14.7k77 gold badges7171 silver badges7070 bronze badges

answered Jul 14, 2012 at 2:04

21k66 gold badges7373 silver badges117117 bronze badges

Depends entirely on how secure it needs to be. Basic auth over ssl will still be sending credentials in plain text, which means you only have one layer of protection.

You would be better off to hash the password with a nonce, or better yet use claims model that passes the auth over to a trusted 3rd party.

answered Dec 5, 2010 at 22:59

15.4k33 gold badges4040 silver badges6666 bronze badges

I am using this myself for many things, and as long as you don't ignore any TLS warnings from the browser you should be good.

TLS works below HTTP, so any data transmitted through HTTP will be encrypted. It'll be as secure as submitting any password form.

Instead of using a self-signed certificate though, I would suggest using Let's Encrypt. They provide free certificates and are trusted by Microsoft, Mozilla, etc., and thus it won't give a TLS warning in the browser. I think it's better to use this instead of a self-signed certificate; if you ever see a TLS error you know it's real and not just because your cert is self-signed.

answered Jul 15, 2012 at 0:47

33.3k88 gold badges8282 silver badges143143 bronze badges

Another argument not mentioned (I guess) so far is the fact that many mobile devices such as smart phones do not let the user check the certificate when doing basic auth over HTTPS in the browser. That means that unlike with forms based auth you cannot bypass the basic auth popup which is a modal dialog on most mobile platforms to check the certificate before you enter your credentials. This might pose a risk when an attacker uses a valid certificate.

answered Mar 6, 2015 at 11:32

Plenty of large and popular sites use basic (or another forms-based) auth over HTTPS. It usually gets a 'sigh' from security-conscious people. Can you hash the password on the client-side and send the hash instead? That would raise the bar a bit more.

That said, it's generally considered acceptable, under the condition that your landing page hosting the logon form is HTTP/S as well. In your case of a RESTful API you probably don't have a landing page so that's okay. If you can, verify your application with some free security tools like Watcher and Skipfish.

answered Dec 6, 2010 at 0:25

1,01411 gold badge66 silver badges1010 bronze badges

Start asking to get answers

Find the answer to your question by asking.

Explore related questions

See similar questions with these tags.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4