Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 34 down vote favorite
11

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?

share|improve this question
1  
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

7 Answers

up vote 34 down vote accepted

There are a few issues with HTTP Basic Auth:

  • The password is sent over the wire in 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 its 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.)

share|improve this answer
2  
"The password must be stored by the server in plaintext" is wrong. As the password is sent by the client on every request, the server can add the salt and hash the result. – Hendrik Brummermann♦ Mar 13 '11 at 4:25
1  
@HendrikBrummermann huh, you're right - I mixed that up with digest authentication. I'm just used to explaining this, I typed faster than my brain... thanks for catching this! Edited that part... – AviD♦ Mar 13 '11 at 8:42
2  
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
2  
@AviD♦ Imho your points 3) and 4) are rarely valid for REST APIs. – user913136 Jun 22 '12 at 19:55
up vote 4 down vote

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.

share|improve this answer
up vote 4 down vote

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.

share|improve this answer
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
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). – nealmcb Dec 6 '10 at 6:23
1  
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 – makerofthings7 Dec 7 '10 at 3:40
3  
Yeah, you're right - BlueCoat does look like corporate malware, using FUD to make business insecure. – AviD♦ Dec 7 '10 at 9:00
1  
And btw - Chrome does use the Windows Certificate Store... – AviD♦ Dec 7 '10 at 9:01
show 3 more comments
up vote 4 down vote

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

share|improve this answer
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
1  
@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
show 5 more comments
up vote 3 down vote

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.

share|improve this answer
1  
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
up vote 1 down vote

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

SSL works below HTTP, so any data transmitted through HTTP will be encrypted. It'll be as secure as submitting any password form, like Stack Exchange's for example.

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

share|improve this answer
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
That StartSSL link looks pretty shady to me. Bad website design. Some negative reviews on the web as well. For any important services, I'd still stick to a more reputable cert provider. – Terry Chia Jul 15 '12 at 5:26
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
up vote 1 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.