How to accept authentication on a web API without SSL?

Question

I'm building a web API very similar to what StackOverflow provide.

However in my case security is importance since data is private.

• I must use HTTP.
• I can't use SSL.

What solution(s) do you recommend me?

EDIT: authentication != encryption

Solution 1

Nearly every public API works by passing an authentication token for each web request.

This token is usually assigned in one of two ways.

First, some other mechanism (usually logging into a website) will allow the developer to retrieve a permanent token for use in their particular application.

The other way is to provide a temporary token on request. Usually you have a webmethod in which they pass you a username / password and you return a limited use token based on if it is authenticated and authorized to perform any API actions.

After the dev has the token they then pass that as a parameter to every webmethod you expose. Your methods will first validate the token before performing the action.

As a side note the comment you made about "security is important" is obviously not true. If it was then you'd do this over SSL.

I wouldn't even consider this as "minimal" security in any context as it only provides a false belief that you have any sort of security in place. As Piskvor pointed out, anyone with even a modicum of interest could either listen in or break this in some way.

Solution 2

Short answer: if it's supposed to be usable through usual clients (browser requests/AJAX), you're screwed.

As long as you are using an unencrypted transport, an attacker could just remove any sort of in-page encryption code through a MITM attack. Even SSL doesn't provide perfect security - but plain HTTP would require some out-of-page specific extensions.

HTTP provides only transport - no secure identification, no secure authentication, and no secure authorization.

Example security hole - a simple HTTP page:

<script src="http://example.com/js/superstrongencryption.js"></script>
<script>
  encryptEverything();
</script>

This may look secure, but it has a major flaw: you don't have any guarantee, at all, that you're actually loading the file superstrongencryption.js you're requesting. With plain HTTP, you'll send a request somewhere, and something comes back. There is no way to verify that it actually came from example.com, nor you have any way to verify that it is actually the right file (and not just function encryptEverything(){return true}).

That said, you could theoretically build something very much like SSL into your HTTP requests and responses: cryptographically encrypt and sign every request, same with every response. You'll need to write a special client (plus server-side code of course) for this though - it won't work with standard browsers.

Solution 3

HTTP digest authentication provides very good authentication. All the HTTP client libraries i've used support it. It doesn't provide any encryption at all.

Comments

[Admin]

Absolute security is not required. Minimum security is.

[Piskvor left the building]

@Pierre 303: Absolute security is impossible. Minimum security is HTTP Basic Auth. However, that's something completely different than what your question asks: "security is importance since data is very private" does not read "minimum security" IMNSHO.

[Admin]

@Piskvor: I want something more secure than Basic Auth. That's the point of my question. Look at Flickr API security scheme. I'm looking into solutions like that.

[Piskvor left the building]

Well, that's again something completely different from both your edits. What exactly are you trying to defend against? Are you trying to pass the user data over the network encrypted (Flickr does no such thing, the actual data is passed in plaintext - not very useful if it's "very private")? Or are you trying to build an authentization/authorization system ("that's Piskvor on the other side, and he has permissions to use this")?

[Admin]

@Piskvor: "very private" should have been written differently. "private" should be better. Data provided by SO is public, anyone can access it outside the API, so there is not reason to authenticate, just protect calls using API keys. However Flickr data is private, so there is a minimum security. I'm looking for that minimum security. I know Flickr scheme, I'm looking for others.

[Admin]

I also answered the question you ask in the comment above.