Rails XML API design practices

Question

I'm building an XML-based webservice in Rails to serve as the backend for an iPhone app, and I'm wondering how I can best achieve an auth scheme that will let me use both GET and POST requests -- i.e. one that doesn't require auth sent in the body of an XML payload.

The wrinkle here is that I'm not using regular HTTP auth. Instead, I'm creating a SHA1 digest of the iPhone's hardware ID (concatenated w/ a "secret" string pre-digest) along with the unhashed ID. I validate it on the server by attempting to re-create the digest w/ the hardware ID from the request and matching it against the hashed hardware ID from the request.

My question is this: should I create my service so that every action on every resource expects a payload of POSTed XML containing the security context in a common XML structure, or is there a better way to do it?

In other words, I'd like to use GET for things like /show, /index, etc. But as my app currently stands, I can't do that, since I need to send an XML payload containing the security context.

Perhaps there's a good way to achieve effectively the same thing with headers a la Google's web API's?

Every security context looks like this:

<request-wrapper>
    <security-context>
        <username>joefoo</username>
        <hardware-id>AE7D128BCA9206E59901</hardware-id>
        <hashed-hardware-id>cfd7983850301f97f6fdc26b553d1b6170f18bde</hashed-hardware-id>
    </security-context>
    ...
    (remainder of request payload)
    ...
</request-wrapper>

This is my first XML service in Rails, so I'd appreciate any general practice advice in this vein as well.

Thanks!

Answer 1

I'm thinking that it might be best to simply use custom headers for this and then access them in my controller filters w/ things like:

request.headers['username']
request.headers['hardware-id']
request.headers['hashedhardware-id']

Any thoughts on whether this is a good/bad idea?

Answer 2

Your authentication scheme is subject to replay attacks if the "secret string" stays the same over the lifetime of the device.

Additionally, the "secret key" (if it is embedded in your application) can be dumped via strings (or other tool) breaking your scheme entirely.

I would instead use an asymmetric key to setup a one-time secret key, and then use it to hash a counter or something. If you need the hardware id for some reason, hash it plus the counter. This is basically a dumbed down SSL implementation, so you might as well just do that frankly (generating your own certificate, and doing the rare mutual authentication; but still...).

Remember, inventing your own security scheme is almost always a bad idea.

Answer 3

How about creating an SHA1 digest of the entire XML request, instead of just the hardware-id? That way you're making replay attacks a lot harder. Sure, without a timestamp and (possibly) a nonce to make each request unique, a hacker could still replay the exact same request multiple times (maybe using up account credits or whatever), but at least they couldn't take the digest from an existing request and change the request details to make it do whatever they wanted.

Suggested steps:

• Take your XML (without any hashed-hardware-id in it) and turn it into a byte array.
• Create an SHA1 digest of the XML byte array.
• Base-64 encode the XML byte array and the SHA1 digest byte array (separately).
• Send the base-64-encoded XML as one request parameter, and the base-64-encoded signature as the other, either using GET or POST.