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.
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).
In case of basic auth, the password "has to be" stored in the browser, which can only be done via a cookie, which can never be considered safe. I posted a similar question here: http://stackoverflow.com/questions/27177224/how-to-keep-state-at-the-client-safely/27177995#27177995 My conclusion was that Basic Auth is NOT safe, that it should NOT be used as such, and that storing sensitive data at the client (such as a user password) should not even be considered.
@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.
The second point is not an issue. Sending credentials with every request keeps your backend stateless.
In addition to the "larger attack window," there's no built-in mechanism like account lock out to protect against brute forcing.
@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.
@LieRyan I honestly don't get it :-\. What's the problem with sending the same string? Is it because variety is the spice of life?
@DavidS: replay attack. Also, if you pass your traffic through a proxy or CDN service, you have some assurance that an attacker cannot attack the proxy/CDN to alter the user's requests.
@Bruno, HTTP Digest is *worse* because it requires the server to store the user passwords in plain text!
@Jacco In principle, the server could only store `md5(username:realm:password)` and not need the password in clear (you can check the content of a file generated with `htdigest` for example). This is implementation dependent. That said, it's still not great (also with the downside of being easily vulnerable to downgrade attacks to Basic).
"Larger attach window" So normal session token that sends as cookie also have the similar problem right?
@JithinJose that wouldn't include the user's password, nor is it static + valid for a very long time.
@LieRyan HMAC isn’t one of the standard HTTP authentication mechanism, unlike Basic and Digest. Were you talking about the one implemented by AWS?
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.
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.
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 and thus you have the premise of OAuth: using another token for auth instead of sending the u/p all the time.
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.
@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.
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.
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.
This makes no sense to me - what scenario are you thinking of? Proxies can't see what is inside an https session, if the browser set it up with the actual endpoint, properly authenticated with a a good cert (or DNSSEC or whatever).
The negative voter should read the linked documentation, since this is a real and valid point that isn't broadly known. Docs: http://www.bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf
Yeah, you're right - BlueCoat does look like corporate malware, using FUD to make business insecure.
Some kind soul should upvote this answer so it's no longer (-1) This answer contains true, factual information
@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!
@MichaelLucas - yes, see the previous comments regarding BlueCoat (a popular malware, erm, software vendor in this space). As I implied, this is an anti-pattern, with numerous downsides (e.g. the user has no indication on invalid or problematic server certs... and that's besides the privacy issues)
@MichaelLucas To my knowledge if they do this properly HSTS cannot defeat this, can you elaborate on how HSTS addresses this? I think you would notice if if you actually take a look at the Certficate Chain in your browser, and begin to wonder why your company is the CA of a third-party site. If my company would do this however, I would complain!
@Nappy Possibly what was meant was HPKP rather than HSTS? That could certainly defeat the nasty corporate scanners. Except that Wikipedia states that most browsers disable HPKP checks for certificates with private roots specifically to allow such scanners. Oh well...
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.
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.
@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.
What about TLS in TLS, I think 4 times wrapping it would be more secure than wrapping it once. This way you can spread the root keys into different locations, so if you use 4 companies to do it, it's likely that they (THEY) won't have the secret root key, or all of them.
@ChrisKuehl So, I guess I will need to dig a little deeper to find a way to set up my server to do a full TLS client authentication?
@StevenLu, your setup sounds fine to me, but it all depends on how much security you want. Just throwing out an additional idea :-).
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.
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.
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.
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?
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).
Update: StartSSL have closed their doors. Your next best option is Let'sEncrypt.
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.