Security best practices . . .

[Chris Alvarado]

Hello,

I am in the process of putting together an API that will ultimately be accessed from various native apps (for iOS / Android) as well as web applications. I have done quite a bit of research on the current state of security for restful services to see if any standards had emerged that address several of the issues than can challenge an exposed API and short of oAuth or the AWS model I haven't found any concrete information, and certainly not much directly related to Coldfusion. As such I am in a bit of a quandary as to how to proceed with that part of my API. Is Basic Auth over SSL truly good enough? If so what does this mean with regards to Taffy? If not a suitable solution can anyone point me towards a better one?

An AWS-like solution doesn't sound bad to me. A public and private key. The private key which is "never" sent across the wire (although how the client is supposed to receive said key in the first place then I'm not sure) is used to hash each request (including a timestamp to prevent a replay scenario) and sent along with the actual request data where the server performs the same hash using the same private key and compares the two to validate the request. It all makes sense (minus the initial setting of the private key on the client). One solution I have seen proposed that would obviously not work for a traditional web app is you ship a application wide private key WITH the app which of course means if the key is in fact compromised you have to disable the key and generate a new one and release an updated client. On the other hand if you issue a new private key to each user (which honestly makes more sense to me) then during their first request you have to send their private key to the client (unless you generate the key using the same data both client and server side, which I suppose makes sense). Or maybe I am just over complicating this.

At any rate, some insight from the Taffy community would be very helpful. I realize this is not an issue specific to Taffy, but as I will most likely be using Taffy to develop my API I figured some of these issues might have already been resolved with Taffy specific implementations.

Thanks for any and all advice.

-c

[Adam Tuttle]

Hi Chris,

I guess the first question I'd ask is what sort of data you're protecting. Unless it's intensely private or sensitive (medical records, social security numbers, etc) then my opinion is that Basic Auth over SSL is good enough.

In this case you just have a new header that you have to include with each request to your API, and the new Taffy 1.3 beta has helper methods for retrieving the username and password when it's been passed.

I think if you were to do a public + private key approach, be cautious about embedding an application-wide private key. While it's easy and fast to release an update for Android, on iOS your users could be out of commission for 2 weeks (on average) or more (in the event of a holiday -- for example, Apple shuts down the review process for a week around Christmas)

If I wanted to do pubkey + privkey my first thought would be to ask them to log into the app, have the app test the credentials via your API over SSL, and return the private key if successful.

Good luck, and let us know how you make out!

Adam

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Chris Alvarado]

Hey Adam,

Thanks for the prompt response. You're probably right that for the data that is being expose via the API in question there is likely no reason to go the shared key route. Thus I will probably end up doing Basic Auth over SSL. When a user successfully authenticates they will be issued an API Key which will accompany all subsequent requests (all of which will be over SSL). When do you anticipate the 1.3 changes mentioned will reach stable status? I realize in the meantime I can inspect the request headers myself for authentication credentials, but it would be nice to be able to further streamline that process with a built-in framework method.

Thanks again for your assistance and for you work on Taffy.

[Adam Tuttle]

1.3 is in beta now, and barring any issues should be finalized no later than early March -- possibly late February.

Adam

Chris Alvarado wrote:

        <javascript:>.

        For more options, visit
        https://groups.google.com/groups/opt_out

        <https://groups.google.com/groups/opt_out>.