3 ms·

> > Key vs Secret > An AWS_Access_Key is basically just a random username. If you understand how userids work in your system, you don't have to worry about thi

> > Key vs Secret > An AWS_Access_Key is basically just a random username. If you understand how userids work in your system, you don't have to worry about this. The big difference is actually that the aws secret key is never sent to the server, but rather used as the secret in an HMAC. That means that if I make a request to S3 with a given secret key, S3 never has access to that secret key (rather it takes my HMAC'd signature, passes it on to the IAM service internally, and gets back a 'yes' or 'no' for if it's correct). That means that S3's logs can't contain sensitive information (the HMAC includes a time, so it can't even be replayed after a short while), any networking dumping I do doens't contain the secret key, etc. This is a useful property in general.

tptacek 9y ago
This is true of lots of API secret schemes that don't have an opaque random key ID. If your secrets are opaque random tokens that only have meaning as an assertion to your servers, it's worth asking yourself what value you'd derive by trying to hide them from server components. And, obviously, something on the serverside will need enough information (almost always: the secret itself) to verify the message.
- lvh 9y ago
  Advocate-of-the-devling re: "something still needs the secret" (assuming you're symmetrically MAC'ing, not asymmetrically signing): yep, but that can be a tiny, separate component and that might be better than everything seeing the plaintext secret. I wouldn't recommend such a scheme by default, because now e.g. your API clients are way hairier to write (e.g. serialization, possibly canonicalization) and it's pretty easy to mess this up (AWS did in their first attempt). But if you have resources to do it well, that is: audit the heck out of the protocol and the tiny component that verifies the MACs, it does prevent some problems mentioned such as unintentional disclosure of the key on the server side, replayability of requests. I don't think those are super valuable properties, but it's also not intrinsically a hare-brained idea. TL;DR: API keys are fine and you should use them but you're not a bad person for wanting to HMAC things :)

tptacek 9y ago

This is true of lots of API secret schemes that don't have an opaque random key ID. If your secrets are opaque random tokens that only have meaning as an assertion to your servers, it's worth asking yourself what value you'd derive by trying to hide them from server components. And, obviously, something on the serverside will need enough information (almost always: the secret itself) to verify the message.

lvh 9y ago
Advocate-of-the-devling re: "something still needs the secret" (assuming you're symmetrically MAC'ing, not asymmetrically signing): yep, but that can be a tiny, separate component and that might be better than everything seeing the plaintext secret. I wouldn't recommend such a scheme by default, because now e.g. your API clients are way hairier to write (e.g. serialization, possibly canonicalization) and it's pretty easy to mess this up (AWS did in their first attempt). But if you have resources to do it well, that is: audit the heck out of the protocol and the tiny component that verifies the MACs, it does prevent some problems mentioned such as unintentional disclosure of the key on the server side, replayability of requests. I don't think those are super valuable properties, but it's also not intrinsically a hare-brained idea. TL;DR: API keys are fine and you should use them but you're not a bad person for wanting to HMAC things :)