API keys are generally not considered secure; they are typically accessible to clients, making it easy for someone to steal an API key. Once the key is stolen, it has no expiration, so it may be used indefinitely, unless the project owner revokes or regenerates the key.
The key consists of code passed between an API and application services. The code calls programs from another application, and the key then identifies the end-user, the developer of the code, and the application making the API call. In this sense, the API key acts as an authentication token or a unique identifier.
The API key ID is included in all requests to identify the client. The secret key is known only to the client and the API Gateway.
HMAC Authentication is common for securing public APIs whereas Digital Signature is suitable for server-to-server two way communication. OAuth on the other hand is useful when you need to restrict parts of your API to authenticated users only.
Basically elaborating on what's outlined here.
Here's how it works: let's say we have a function that takes a number from zero through nine, adds three and, if the result is greater than ten, subtracts ten. So f(2) = 5, f(8) = 1, etc. Now, we can make another function, call it f', that goes backwards, by adding seven instead of three. f'(5) = 2, f'(1) = 8, etc.
That's an example of a two-way function and its inverse. Theoretically, any mathematical functions that maps one thing to another can be reversed. In practice, though, you can make a function that scrambles its input so well that it's incredibly difficult to reverse.
Taking an input and applying a one-way function is called "hashing" the input, and what Amazon stores on their system is a "hash" of your secret key. SHA1 is an example of this kind of "one-way" function, it's also hardened against attacks.
The HMAC function builds on established hash functions to use a known key to authenticate a string of text. It works like this:
The difference between this and PKI is that this method is RESTful, allowing a minimum number of exchanges between your system and Amazon's servers.
Isn't that basically the same thing as asking me for my credit card numbers or password and storing that in their own database?
Yes, though the damage someone can do with S3 seems to be limited to draining your account.
How secret do they need to be? Are these applications that use the secret keys storing it somehow?
At some point, you're going to have to load the secret key, and with most Unix based systems, if an attacker can get root access they can get the key. If you encrypt the key, you have to have code to decrypt it, and at some point the decryption code has to be plain text so it can be executed. This is the same problem DRM has, except that you own the computer.
In many cases, I just put secret keys in a file with limited permissions, and take the usual precautions to prevent my system from being rooted. There are a few tricks to make it work properly with a multiuser system, such as avoiding temporary files and such.
Public Key Cryptography is used to defend against very specific attacks, some of which are common. In short this is complex math that allows one to verify that at individual has both the Public and Private Key pair while only knowing the public key. This is very different from a credit card or static password. As an example if you are authenticating with an OpenSSH server then the server doesn't need the private key.
Ideally if Amazon's API database where to be compromised the attacker would have a list of public keys and would be unable to access the user's API using this information. However ideal systems are not always put into practice and i don't know for sure if Amazon is protecting against this attack vector, but they should be.
In public key authentication is statistically immune to brute force. Passwords are often dictionary words which can be broken relativity fast. However a private key is a massive number that isn't easy to guess. If the attacker had the public key then they could perform many guesses "offline" on a super computer, but even then it would take a lot of time and money to break the key.
AWS has designed their own custom authentication algorithm. v4 was released in 2014. Details are outlined here: Authenticating Requests (AWS Signature Version 4) . A major point is that the request is not signed with the secret itself, but with a signing key which is generated using the secret. It also uses HMAC-SHA256 for signing.
Using asymmetric keys would be safer since AWS would only store a public key instead of the secret, which is stored by both the user and AWS.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With