5

Does anyone know why Google and Amazon (AWS)'s API have such different ways to deal with security? For example, Google has a simple API key which you can revoke at any time, while Amazon has this public/secret key mechanism in addition to a complex request signature requirement.

Amazon's signature process is so complex that it looks more like obfuscation than real security? You're almost forced to use their SDK unless you feel like spending a few hours into figuring out the requirements.

Why are the two approaches completely different, and does Amazon's signature truly add security to their API? Why would Google use such a simple alternative? Is Amazon's approach really useful considering that they also enforce HTTPS?

Miller86
  • 212
  • 1
  • 7
Nicolas Bouvrette
  • 103
  • 8

2 Answers2

7

I think the question here should more be answered from a marketing than a security perspective.

In general, I would say that Google probably uses a relatively simple API key for usability/accessibility, in order to make it easier for the mass of developers to implement their services (and earn money from that).

Amazon probably has more concerns about the use of their API and uses a different system of public and secret keys. The use of a secret key does add a certain protection and can not directly be considered as security-by-obfuscation (while technically most security is basically a form of obfuscation).

To answer your question in the comment:

I'm actually curious to understand why would anyone want to make public (lucrative) service hard to use. Other than complexity what other gains is there to signature VS using a key?

Two reasons came to my mind about this:

The first one is probably that it gives a sense of security and this can be a reason for companies to choose a harder to implement service above an easy-to-implement service. Because it's considered "more secure". This raises the question if the security features are actually adding an extra layer of security or if they just complicate things unnecessarily.

The second one is probably that it can actually add extra security. When we, for example, use a service that charges money for each request and the only authentication is one key. Then, if the key leaks, anyone can use that API using my key and so I will get charged for it. An example of an extra security layer is IP whitelisting in combination with the key. This mitigated at least the problem that anyone can misuse my key. SSL (HTTPS) adds a layer of encryption to the communication between the server and the client (possibly mitigating man-in-the-middle attacks). Other possible features or measures can be DNSSEC, custom encryption, time-frames, key/credential expiration et cetera, all adding actual security to mitigate different attacks.

For the vendors, it is (as often with security) a constant consideration between usability and security. They will consider things like:

  • How far can and should we go, without getting paranoid?
  • How far do we need to go to protect the services (data) we offer?
  • Is it still acceptable by developers if we go this far?
Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
  • I'm actually curious to understand why would anyone want to make public (lucrative) service hard to use. Other than complexity what other gains is there to signature VS using a key? – Nicolas Bouvrette Aug 04 '16 at 13:03
  • 1
    As @KevinMorssink pointed out it *is* more secure. Whether or not its more secure enough to be worth the UX hit is a matter of opinion. – Jared Smith Aug 04 '16 at 13:15
  • @NicolasBouvrette I added some additional information regarding your comment. – Bob Ortiz Aug 04 '16 at 13:15
  • So to sum up, given their SDK is easy to use/grab, their conplex signatures will most likely make their API less friendly to use and more CPU heavy at the cost of adding a potential 1 hour delay to a motivated hacker? :) I personally don't think it's a good decision but then again I prefer simple solutions. – Nicolas Bouvrette Aug 04 '16 at 13:23
  • @NicolasBouvrette basically it's a consideration between usability and security. I added a small extra section in the answer again. And theoretically, every security measure is just obfuscation and delaying a hacker (some for some seconds or hours, some for years or decennia). – Bob Ortiz Aug 04 '16 at 13:26
0

I have worked with building my own wrapper for part of Amazons product API, and It was very very difficult to use.

I believe this is because the amazon API (at least the marketplace API) has to deal with rapidly changing data, and allowing third parties access to display this marketplace requires large amounts of restrictions to guarantee that the displayed objects are accurate.

The API call includes making a signature (with a timestamp included) to prevent manipulation of data based on time. (Perhaps showing prices for a product that in reality are prices from years ago?)

user113163
  • 1
  • The timestamp seems to be part of all signatures from what I could tell. I even saw some thread for v3 of people conplaining about their API being down because the 300 seconds delay check didn't take in account some timezones. On v4 the delay seems more flexible (1 week?) which is why it looks more like obfuscation to me. – Nicolas Bouvrette Aug 04 '16 at 13:42