Is this a safe authentication scheme for my site's API?

Question

I'm currently building a database app for my church which deals with some fairly sensitive data..

The app is written in ruby on rails,

We are also looking to extend it with an iPhone app.

I'm currently trying to find the best solution for authenticating users of the iPhone app and here is one solution i came up with:

1. iPhone app issues a handshake request (over SSL) which returns a JSON string with 2 values: api_key and api_secret.

2. Any subsequent requests are appended with 2 additional params api_key and api_signature the api_signature is basically the api_secret hashed together with the users email to obscure the secret.

3. The rails app authenticates the signature by hashing together the api_secret and the users email and comparing it with the signature passed in..

4. The app gets it's data :-)

5. The api_secret is invalidated and recreated every 2 hours (so if a hacker got hold of it they'd only have a valid secret for 2 hours..)

As clever as i thought this was.. I see one glaringly obvious scenario:

What if a hacker got hold of the api_key and the api_signature anyway..

If they append their request with those params they're in so what's the point in all my obsfucation?

How would you better implement this?

Thanks very much!

Answer 1

I think your problem is the static signature.

If you look at how AWS do it (I'm a fan of not re-inventing wheels if someone else is already doing it well), their signature is hashed from all the parameters of the request, one of which is mandated to be a timestamp.

This is important as it means the signature is rapidly changing even for repeated requests for the same data. Mandating a timestamp also means you can ensure requests have a relatively short validity, assuming the clocks on both client and server aren't too far apart. I certainly wouldn't have it as long as 2 hours - I'd reduce the window to maybe 15 minutes.

Think of it like the public and private keys. You can publish the public key (the api_key) but the private key must be known only to the client and the server.

The private key should not be transmitted in requests, and transmitting a static hash of it isn't great either - hence the approach Amazon take.

If you do need to transmit the private key to the device to start with, I'd feel very uncomfortable about transmitting it in the same payload as the api_key, but you should probably take advice from a security expert at this point as I'm out of my depth and happy to admit it.

Answer 2

Fortunately, your problem is not unique, so there's no need to re-invent anything. Just use Digest access authentication . I don't know that much about Ruby on Rails, but I do know there is support for it . You can get the client-side implemented for iPhone, too, using ASIHttpRequest , so you don't have to invent any security scheme.