# 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?

• Yes, the http user/pass will be OK as it goes over SSL, but the password has to be strong. – Andrew Smith Jul 14 '12 at 1:20
• Well, i could put some logic in my server that bans a client that attempts too many passwords. Would that prevent DoS and password guessing? – Steven Lu Jul 14 '12 at 1:28

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.)

• actually, even with HTTP Digest, you may be able to a hash of the password (md5(username:realm:password), sometimes called HA1). – Bruno May 18 '11 at 20:58
• @AviD♦ Imho your points 3) and 4) are rarely valid for REST APIs. – Eugene Jun 22 '12 at 19:55
• @KimGysen for Basic Auth, the password is NOT transmitted or stored in a cookie, it is sent in the Authorization: request header, and stored in a special (protected) part of the browser's memory. Not that I disagree with you, in the general case Basic Auth should not be used, however there are certain situations where the tradeoff might be viable. – AviD Nov 28 '14 at 8:38
• In addition to the "larger attack window," there's no built-in mechanism like account lock out to protect against brute forcing. – Alex Kuhl Mar 6 '15 at 16:08
• @Artjom: Sending Basic credentials on every request is an issue, not because you have to keep sending the credentials, but rather because the same string is sent on every request. There are other authentication mechanisms, like HMAC, where the Authorization header cannot be decrypted back to the user's secret, and the server can authenticate the request without actually knowing the user's secret. In this mechanism, the string sent on the Authorization header changes based on the hash of the request. – Lie Ryan Aug 6 '15 at 14:28

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).

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

• There is one slight difference between those situations: with http basic authentication the password is sent for every request, while with a form based login it is sent only once and then something like a session cookie is used. This very slightly decreases the attack surface. – Pepijn Schmitz Nov 4 '15 at 10:51
• The user password are sent only once but the auth cookie is sent on every request too, so the question is only to send the user and password instead cookie auth – deFreitas Feb 8 '16 at 12:46
• @deFreitas and thus you have the premise of OAuth: using another token for auth instead of sending the u/p all the time. – cottsak Mar 2 '16 at 5:27
• I think there is more than a slight difference: in the form POST example, the initial page rendering has to be sent over HTTPS before the user decides to enter their credentials and POST them back (securely). With HTTP basic auth, even if the server refuses to service a non-HTTPS request and redirect to HTTPS, the credentials have already gone over the wire insecurely and are then venerable to MiTM snooping. The client has to decide to POST HTTPS initially or risk an insecure channel. This is less likely with the form POST scenario. – cottsak Mar 2 '16 at 5:30
• @PepijnSchmitz I would note the difference of a session key (which can be invalidated) is hugely different than having login credentials stolen. Damage can still be dealt while another party has your private session key, but it's much more limited in nature, especially since you can have your application log out from the API after it's finished executing to invalidate the key. – Jeremy Kato Aug 5 '16 at 18:12

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.

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.

• Actually this depends on what site you're talking about. E.g. if youre browsing to your bank from work, and they use Basic Auth, that's not getting decrypted by the proxy at your work. SSL goes right through that. – AviD Dec 6 '10 at 6:16
• The negative voter should read the linked documentation, since this is a real and valid point that isn't broadly known. Docs: bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf – goodguys_activate Dec 7 '10 at 3:40
• Yeah, you're right - BlueCoat does look like corporate malware, using FUD to make business insecure. – AviD Dec 7 '10 at 9:00
• And btw - Chrome does use the Windows Certificate Store... – AviD Dec 7 '10 at 9:01
• @AViD, there are some cases where corporate proxies actually do decrypt the SSL traffic, by presenting their own certificate (which is signed by an internal corporate cert that is imported as a trusted root authority cert on all corporate workstations). My company does this for a few sites including Gmail (but not for banking sites). It works, and is often invisible to users because the company also manages the desktops/browsers. Note that Strict Transport Security (HSTS) can defeat this ... it was the firefox HSTS warning that alerted me to it in the first place! – Michael Lucas Dec 17 '15 at 17:28

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.

• If you are going self signed, be sure to communicate what the SHA1 and MD5 fingerprints of the certificate should be so they can verify its legitimacy upon connection. Or distribute ahead of time, if feasible. – chao-mu Jul 14 '12 at 3:27
• There is another concern with using HTTP basic authentication: the full password is sent over the SSL tunnel. In other words, the password is not hashed before being submitted, and could thus possibly be captured (bug in your application code, etc). This is usually not a major concern (this is true for most passwords you submit over HTTPS, even in website login forms, and even in password SSH), but is worth taking note of. – Chris Kuehl Jul 14 '12 at 4:43
• @ChrisKuehl Aren't there strong arguments against doing any crypto in client-side javascript? Is that what you are suggesting? Seems to me like TLS is about as good as I can get other than paying for signing the certificate. – Steven Lu Jul 14 '12 at 9:23
• @StevenLu not that I'm aware of or that I can find quickly, but I'd be interested in reading anything about the topic. I can't see any way that hashing something preliminarily before sending it serverside could decrease security, even if serverside further hashes it before storing it. I would be tempted to use SSL/TLS auth instead (modern browsers allow 2-way auth with websites using key auth), especially for a page that is not meant to be viewed by regular users. This depends a lot on your use case, though, and is probably difficult with your Python webserver. – Chris Kuehl Jul 14 '12 at 17:08
• @StevenLu interesting, but missing the point; TLS auth, as implemented in browsers, doesn't involve JavaScript. It's a feature of the browser itself. There are issues that make it not suitable for use with user-facing authentication, but for developers/admins, I think there's a strong case that can be made for it. – Chris Kuehl Jul 14 '12 at 23:00

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.

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.

• only a challenge-response with hash is an upgrade in security, otherwise the attacker can just snoop the hash and still get access when the session expires – Hubert Kario Jul 19 '11 at 22:14

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.

• I'd definitely do something like this especially if it's free. The "invalid certificate" errors are pretty glaring. – Steven Lu Jul 15 '12 at 1:08
• Yes, StartSSL is really a sorta homebrew solution, but it's trusted by big parties so I guess it's fine as long as you don't secure anything worth millions with it. Anything is better than a self-signed certificate. The way to make self-signed secure is to check the fingerprint, but you can still do this while using (for example) StartSSL. – Luc Jul 15 '12 at 17:59
• I am hosting my secure content on a different server from one which I can set the target domain for a certificate (to be issued by StartSSL). This is because I am not paying for a VPS with a static IP, I am using the No-IP service to give me a redirect to my IP. Is it possible for me to obtain a key/certificate that will allow me to open my site from anywhere without it showing invalid cert errors? – Steven Lu Jul 17 '12 at 3:54
• So it seems to be clear to me that with a dynamic IP there is absolutely no way to set up a proper SSL certificate. Okay I guess I am stuck with the browser error then (unless I do some kind of proxy setup). – Steven Lu Jul 17 '12 at 4:02
• @starbeamrainbowlabs Thanks! I updated the answer. – Luc Dec 17 '17 at 12:35

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.

Here is a bit more context for history. Just like others said Basic Auth over TLS works well if you can live with a few limitations.

Used on the client side, you probably need to deal with session management, which is rather hard with Basic Auth.

On the backend, Basic Auth performs well but relies entirely on TLS for confidentiality and integrity. It is similar to token based auth. If you need anything more sound, consider using a signature schemes or TLS Client Auth.