How to accept authentication on a web API without

问题:

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

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

回答2:

First of all, I suggest you read this excellent article: http://piwik.org/blog/2008/01/how-to-design-an-api-best-practises-concepts-technical-aspects/

The solution is very simple. It is a combination of Flickr like API (token based) and authentication method used by the paiement gateway I use (highly secure), but with a private password/salt instead.

To prevent unauthorized users from using the API without having to send the password in the request (in my case, in clear since there is no SSL), they must add a signature that will consist of a MD5 hashing of a concatenation of both private and public values:

• Well know values, such as username or even API route
• A user pass phrase
• A unique code generated by the user (can be used only once)

If we request /api/route/ and the pass phrase is kdf8*s@, the signature be the following:

string uniqueCode = Guid.NewGuid().ToString();
string signature = MD5.Compute("/api/route/kdf8*s@" + ticks);

The URL of the HTTP request will then be:

string requestUrl = 
     string.Format("http://example.org/api/route/?code={0}&sign={1}", uniqueCode, signature);

Server side, you will have to prevent any new requests with the same unique code. Preventing any attacker to simply reuse the same URL to his advantage. Which was the situation I wanted to avoid.

Since I didn't want to store code that were used by API consumer, I decided to replace it by a ticks. Ticks represents the number of 100-nanosecond intervals that have elapsed since 12:00:00 midnight, January 1, 0001.

On server side, I only accept ticks (timestamp) with a tolerance of +-3 minutes (in case client & server are not time synchronized). Meaning that potential attacker will be able to use that window to reuse the URL but not permanently. Security is reduced a little, but still good enough for my case.

回答3:

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.

回答4:

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.