3 ms·

You HMAC the region so that in case a region is compromised, other regions aren't as well. You HMAC the service so that in case a service is compromised, other

You HMAC the region so that in case a region is compromised, other regions aren't as well. You HMAC the service so that in case a service is compromised, other services aren't as well, you HMAC the timestamp for obvious reasons (time bound the signature), the outer "aws4_request" HMAC, I'm sure there's a good reason for. Maybe just versioning? Not sure. Also: All of this is handled in the SDKs. Anyone implementing this themselves either isn't using the right libraries or has a very special use case.

dividuum 4y ago
Sounds like OP is having a bit of a Chesterton's Fence moment. It's clearly complicated, but you describe why this is probably implemented the way it is. The scheme reminds me of Macaroons: https://blog.gtank.cc/macaroons-reading-list/ https://blog.gtank.cc/macaroons-reading-list/
naasking 4y ago
I'm sure there are "reasons" why the HMACs are layered, the question is, does using HMACs actually add useful security properties here, or is this layered HMAC really just a way to generate a cryptographically secure id? If the latter, then can't you just generate that directly rather than needing to gather all of the right information and HMAC it in just the right way?
- mcqueenjordan 4y ago
  Sorry, how do you propose to transmit a signature over the wire such that if it were compromised, the blast radius is limited to only the called service within the called region within a finite time window?
  - naasking 4y ago
    Is the signature even necessary? As I said, an opaque bearer token is considerably simpler. Generate as many as you need for whatever services you're running to limit the damage of a leak. Set server-side policies for expiration or whatever else.
    - mcqueenjordan 4y ago
      This would compromise on security (for this scheme, time window will presumably be longer, many more keys that can be compromised) and would create an explosion of keys for the user to manage, effectively offloading that work to your customers. I don't know that it would present a simpler experience to force your customers to have a different key for every service for every region. Anyway, this is from the perspective of a large service provider. For side projects or smaller services, yeah simple can be good. But it really depends on your security requirements, threat model, customer requirements, etc.
- dastbe 4y ago
  when a request hits the server authenticating you, it has to recreate the signature. aws doesn’t want to provide those services your raw credential because that makes any aws host a very juicy target. instead, they provide the partially evaluated signature including region and service and then they continue the process. this means that if you compromise an ec2 host, the only credentials you get are usable against ec2. the idea is that if you were able to achieve that, you likely don’t even need those credentials to do worse things to ec2.
  - naasking 4y ago
    > when a request hits the server authenticating you, it has to recreate the signature Authentication doesn't require signatures, that's my point. They often place the burden of getting the security right on the client.
    - dastbe 4y ago
      so you mention bearer tokens in another comment, so i’ll speak to that. while bearer tokens are simpler, the protection they provide is more limited. for example, a bearer token has no request affinity so if i get your token for service foo from a request you made, i can impersonate you for the lifetime of that token. and it’s much easier to get your token, because it has to live your physical machine to be of any use. with bearer tokens, the only way to reduce blast radius is to generate more tokens. get a token per-service/region, get a token every 5 minutes, etc. this is possible, but comes at the expense of availability. if the token vendor is down, the impact of the outage is proportional to how frequently and in what situations a caller needs to get a new token. with signatures and client computation of scoped keys, you’re able to use much longer lived credentials while generating short term credentials only where necessary for that request.

dividuum 4y ago

Sounds like OP is having a bit of a Chesterton's Fence moment. It's clearly complicated, but you describe why this is probably implemented the way it is. The scheme reminds me of Macaroons: https://blog.gtank.cc/macaroons-reading-list/ https://blog.gtank.cc/macaroons-reading-list/

naasking 4y ago

I'm sure there are "reasons" why the HMACs are layered, the question is, does using HMACs actually add useful security properties here, or is this layered HMAC really just a way to generate a cryptographically secure id? If the latter, then can't you just generate that directly rather than needing to gather all of the right information and HMAC it in just the right way?

mcqueenjordan 4y ago
Sorry, how do you propose to transmit a signature over the wire such that if it were compromised, the blast radius is limited to only the called service within the called region within a finite time window?
- naasking 4y ago
  Is the signature even necessary? As I said, an opaque bearer token is considerably simpler. Generate as many as you need for whatever services you're running to limit the damage of a leak. Set server-side policies for expiration or whatever else.
  - mcqueenjordan 4y ago
    This would compromise on security (for this scheme, time window will presumably be longer, many more keys that can be compromised) and would create an explosion of keys for the user to manage, effectively offloading that work to your customers. I don't know that it would present a simpler experience to force your customers to have a different key for every service for every region. Anyway, this is from the perspective of a large service provider. For side projects or smaller services, yeah simple can be good. But it really depends on your security requirements, threat model, customer requirements, etc.
dastbe 4y ago
when a request hits the server authenticating you, it has to recreate the signature. aws doesn’t want to provide those services your raw credential because that makes any aws host a very juicy target. instead, they provide the partially evaluated signature including region and service and then they continue the process. this means that if you compromise an ec2 host, the only credentials you get are usable against ec2. the idea is that if you were able to achieve that, you likely don’t even need those credentials to do worse things to ec2.
- naasking 4y ago
  > when a request hits the server authenticating you, it has to recreate the signature Authentication doesn't require signatures, that's my point. They often place the burden of getting the security right on the client.
  - dastbe 4y ago
    so you mention bearer tokens in another comment, so i’ll speak to that. while bearer tokens are simpler, the protection they provide is more limited. for example, a bearer token has no request affinity so if i get your token for service foo from a request you made, i can impersonate you for the lifetime of that token. and it’s much easier to get your token, because it has to live your physical machine to be of any use. with bearer tokens, the only way to reduce blast radius is to generate more tokens. get a token per-service/region, get a token every 5 minutes, etc. this is possible, but comes at the expense of availability. if the token vendor is down, the impact of the outage is proportional to how frequently and in what situations a caller needs to get a new token. with signatures and client computation of scoped keys, you’re able to use much longer lived credentials while generating short term credentials only where necessary for that request.