I am building a web application and RESTful web service.
I have been reading various articles about the best way to authenticate the requests to the web service.
The best option for me seems to be to use HTTP basic authentication. Pretty much every article ive read says that authentication should be encrypted over SSL or equivalent.
Im not totally sure what this involves. Does this mean that my whole web service will have to be on a secure server? Will this slow things down?
First of all, try to understand how SSL (HTTPS) and HTTP authentication works.
The usual HTTP authentication methods (Digest, Basic, and any forms+cookie based authentication scheme you can implement on top of HTTP) are all insecure by themselves, because they send authentication information more or less in clear text. Whether the data is in POST fields or headers, and whether base64-encoding is applied, doesn't matter at all in this regard, the password is clearly visible to anyone with access to the network traffic. This means that HTTP authentication over an untrusted channel is worthless: all it takes for an attacker to read your password is a little network sniffing.
SSL implements a secure communication channel over an inherently insecure channel. This works, roughly, as follows:
Note a few important points here:
So obviously, there is some overhead involved, but it's not as bad as you'd think - it's mostly on the scale where "throw more hardware at it" is the appropriate response, unless you're preparing for absolutely massive amounts of traffic (think Google or Facebook). Under normal circumstances, that is, typical web application usage, the SSL overhead is negligible, and consequently, as soon as you have any confidential data at all, it's best to just run everything over SSL, including resources. SSL is also the only viable way of securing HTTP traffic; other methods are simply not as standardized and thus not widely supported, and you absolutely do not want to implement these things yourself, because honestly, it's just too easy to get them wrong.
TL;DR: Yes, SSL + Basic Authentication is a good idea, yes, you need a secure server (and a valid certificate), yes, it will slow things down a bit, but no, this is not something to worry about right now.
HTTPS (SSL) isn't user authentication FYI. It just provides encryption between 2 endpoints.
But yes, there is a teeny tiny bit of overhead from it (though not enough to warrant a change in plans/hardware). See here :
https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
With HTTP basic authentication, the username and password the user provides is sent with every request to the server. This means they are in plain text even in areas of your site that don't necessarily need to be secure. Obviously, you'll want SSL here to keep your users safe.
In theory, you could use cookie authentication and only put SSL on the login page(where the username and password is sent). If your cookies are decently secure and safe against replay attacks, then an attacker wouldn't be able to do anything with them even if they did manage to get one.
Basic authentication is setting a username and password in the header of the http request. If you don't use SSL or equivalent then that username and password is sent in plain text and is trivial for anyone to steal.
Most web servers support HTTPS out of the box nowadays and although it does add overhead to every call that overhead is minimal.
You could secure some endpoints and not others (ie have an authenticate endpoint that produces a token that can be used for other calls). I would strongly recommend SSL for the whole service though as its much more secure. (if nothing else it stops sensitive data being intercepted)
Jeff Atwood wrote a brief blogpost not so long ago about whether full encryption is the way to go. He describes some real-world examples and has a few lines on performance considerations too.
Also, he references this article about a Gmail case study, quoting the following:
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
He also mentions some then-recent improvements to client-side caching of pages through HTTPS by the browser.
Despite this, he points out, there are other penalties, most of them being not performance but implementation costs:
HTTP basic auth without your own session handling will probably leave you open to Cross-site request forgery attacks. You can probably use it if you couple with your own session handling, but you may have trouble providing a clean "log out" function.
No matter what you use for authentication, you will need to use HTTPS to encrypt the connection (unless the web application is only accessed on a controlled, secure network). It may slow things down a bit (connection establishments are expensive, but browsers tend to keep connections for a while), but if you want a secure application, you won't be able to avoid it anyways, so you don't really need to worry about it.
Note: "HTTPS authentication" (which you mentioned in the title) is misleading - it could refer to SSL client certificate authentication, which has little to do with the text of your question and has it's own set of benefits and problems. You probably don't want to touch that.
How are you going to accomplish the basic authentication?
If it is a hard coded username/password and you are using your webserver's built in functionality to do it, it will likely have a near zero impact. If you are off doing crazy things in a database or something similar, then yes there could be an impact.
Like others have noted here, SSL & sending the extra headers will technically make things slower but it will not be significant in any way.
