Cloud API Security was the topic for a panel discussion at the Infosec conference in London April 26th. After a brief introduction of what APIs are, how companies are becoming platforms and what security implications this has the discussion mostly focused on how to secure mobile apps and how to keep security tokens protected.
There is a significant risk with baking in a security token in a mobile app. It is quite easy to listen to the traffic between the app and the server and catch the token, even if the traffic is encrypted. Once the token is out the only way to handle the situation is to use a new token and release a new version of the app. This in turn requires users of the app to update before the old token can be invalidated. To get all users to update within a small time frame is almost impossible, so the security breach will remain for a long time.
Instead of baking in the security token in the app it is better to put the security on the user level instead of in the app level. Let the user authenticate the data access, for example via OAuth 2.0. This means that there is no risk that a token giving access to all the data can get into the wrong hands, because such a token does not exist. Also, if there is a security breach and a token has fallen into the wrong hands it is easy for a user to invalidate the token and create a new one without involving any other party.
The recent security problems with the Facebook Android SDK shows that there is an inherit risk of using 3rd party modules. In that case a security token was by mistake left in a log file that another 3rd party application could access. The SDK lowered the bar of creating a Facebook Android app, but it also propagated the error. Even if Facebook acted quickly and patched the security hole it did not really help since it requires all app developers using the SDK to update, and all the end-users using those apps to update. Since this is not going to happen in 100% of the cases it means that insecure SDK implementations will be out there for a very long time. One way to get around such a problem is to build web apps instead of native apps. Then any security problem can be quickly fixed in one central location and there is no need to wait for users to update their local versions of an application.
Letting somebody else get access to your security token is the same as letting them get access to your credit card. They are free to impersonate you to get at your data and run up your tab while doing so. This can be very expensive for APIs that charge a premium for access. Developers need to be aware of this connection and treat security tokens just as they do their credit card.
One way of making security tokens more secure is to limit the access of a given as much as possible. Do not use one token or key for an entire corporation, instead tie the token to a specific user. This limits the potential damage as well as creates clear accountability in case something happens.
It is clear that APIs is an area that can not be ignored anymore andæ that companies soon will have to provide APIs to survive. Having APIs exposed to 3rd parties brings with it a new set of security problems of which we all need to be aware. Since technologies change so rapidly it is important to use a pluggable and extendable security solution that allows for quick adaptations rather than to be stuck in one scenario. This security solution need to be able to handle core security services such as federation, single sign on and user authentication.
Participants in the panel were Travis Spencer from Ping Identity, Steven Willmott from 3Scale, Per Hägerö from Technology Nexus and Andreas Krohn from Dopter. Moderator was David Terrar from Eurocloud UK.