How (not) to implement AWS4-HMAC-SHA256
Speaking as a developer who has implemented AWS4-HMAC-SHA256
on a service (YourCrowd, which maintains MTurk compatibility), I always find it interesting to see how fellow tech companies accomplish the same goal.
Today I ran into Telnyx, which offers S3 compatible storage.
Instead of implementing AWS-HMAC-SHA256
... Telnyx has just shoved a secret access key where a access key ID was supposed to be.
Putting the HMAC key in the same HTTP request as the signature is similar to locking a safe but then leaving the key right next to it.
The purpose of the signature is to ensure that the message hasn't been tampered with and comes from a trusted sender. If an attacker intercepts the HTTP request, they could use the HMAC key to generate their own valid signature for a tampered message.
Here's a breakdown of why you shouldn't include the HMAC key in the same HTTP request as the signature:
- Defeats the purpose of authentication: The HMAC key is used to verify the authenticity of the message. If it's provided in the same request, an attacker could tamper with the data and generate a new signature.
- Increases risk of key compromise: Transporting keys always risks them being compromised. Accidental logging is a real risk as most libraries are not expecting the access key ID to be misused as a secret key. The more places a key is stored or transmitted, the more places an attacker can potentially find it. By not including the key in the request, you're reducing the attack surface.
- No benefits: There's no benefit to including the key in the request. The receiving server should already have the key necessary to validate the signature.
It appears Telnyx agrees that there's no benefit.. so they just aren't bothering with signatures at all. 🤦 There's no actual HMAC signature verification, it's really only validating requests based on your access key ID.
This is more like AWS--
instead of AWS-HMAC-SHA256
.