views:

29

answers:

1

We're developing a REST API to be consumed by a couple of mobile applications. It's important that we're able to trust the identities of these mobile applications. In our current design, each API call is authenticated with an "API Key" parameter and secured with HTTPS.

My concern is that the API Key is embedded within each copy of the mobile app, which means there's no way we can keep it secret. It will be on thousands of phones, and theoretically any hacker with a binary editor or HTTP Traffic analyzer could extract the API key and then 'pose as' one of the applications, sending us requests that we'd have no choice but to trust. Client certificates would appear to have the same risk.

Is there an architecture that solves this problem?

+2  A: 

It is being discussed from time to time in different places including StackOverflow. In brief - whatever you put to user's possession is not yours anymore. You can obfuscate the private key, of course, yet I see at least three ways to bypass your security measures.

The only way to solve a problem could be to employ cryptographic device (smartcard or USB cryptotoken) which keeps private and secret keys and doesn't let them out, however with handhelds use of such devices is quite complicated (if not impossible) from both technical and usability points of view.

Also you might want to reconsider your approach and let any client software use the service given that they pay for it. And your server will authenticate users and not software. Then the topic of keeping login data secret will be users' task.

Eugene Mayevski 'EldoS Corp
note too that you can add the IMEI (android) or UUID (iphone) to help in identification. make sure this matches with the customer (send a confirmation email?)
KevinDTimm
Good points. Charging per API call would certainly help incentivize better private key security, but our business relies on the API being free and the apps easy to use. Its a given that our server will authenticate users - what we don't want is a fraudaulent app out there trying to steal users' passwords or brute-force credit card details through our API.
realworldcoder
@RealWorldCoder trying to authorize your apps is probably not the best way to prevent misuse of the API, especially if such misuse can constitute theft of credit card details. I'd better make the API more robust to prevent such possibilities.
Eugene Mayevski 'EldoS Corp
@Eugene - there is already rate-limiting by IP for CC authorizations. Perhaps ways of improving the API require a separate question.
realworldcoder