5

The API of a mobile app I was testing is sending the AWS AccessKeyId and SecretKey used for request signing from the AWS Cognito server unencrypted (apart from the regular TLS encryption). Making it possible to re-sign all requests to their AWS Lambda API, e.g. using Burp's "AWS Signer" extension.

With this, a Man-In-The-Middle could sign all altered requests, so I wonder what the actual use case of request signing is, in this instance?

Shouldn't the AccessKeyID and SecretKey be kept secret?

The owner of the app is telling me that this is not an issue because they are following the AWS guidelines.

Is that correct? Or are they doing something wrong?

Why would they sign the requests in the first place in their mobile app? What is the use case of signing the requests, when the 'secrets' for creating a signature are distributed via the same connection in clear (except TLS)?

Is this conform with best practices, when using AWS Lambda for serverless mobile app APIs? Is request signing even useful in this instance? Most apps I have tested didn't use request signing.

1

You're right. The mobile app developer is incorrect. There is NO reason to share the SecretKey.

In fact they should not ship it with the application.

TL;DR;

There's an engineering principle that applies to security here - KISS or keep it simple, sir.

Reading AWS documentation and request security, it's clear they go though elaborate hoops to keep the access secret key private and do not expect you to share it.

The request signature you talk about is an elaborate way of letting AWS determine if the person who knows the SECRET actually sent the request. If they also send the secret then yes, any MITM can intercept and "prove" they also hold the secret because they clearly do.

Back to the KISS principle - the principle in this case is NEVER SHARE THE SECRET. It's that simple.

0

Shouldn't the AccessKeyID and SecretKey be kept secret?

According to this:

Yes, they should be kept secret.

With this, a Man-In-The-Middle could sign all altered requests, so I wonder what the actual use case of request signing is, in this instance?

According to this

AWS access key ID is a form of unique user/account identifier

And

AWS secret key is like private key

So the signing is a way to authenticate\identify a user

Why would they sign the requests in the first place in their mobile app? What is the use case of signing the requests, when the 'secrets' for creating a signature are distributed via the same connection in clear (except TLS)?

The reason why they designed it like this we would never know, but sending such a sensitive information in cleartext is not a good idea. However, according to this

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.

enter image description here

Thus, The AWS latest authentication mechanism simply will not accept secret key. It authenticate API requests based on the aforementioned way.

3
  • Yes I am aware how signing works, but that was not the question, I'm afraid. – Martin Fürholz Feb 16 '20 at 21:58
  • Hi Martin, I am absolutely sure that you know that, just wanted to point that: 1. It's not ok to transmit SecretKey during API signing. 2. Even if they transmit SecretKey during API signing in plaintext, AWS will not accept it. It's the same as if someone would try to use plaintext password lookup on a hashed&salted password database - it will simply will not accept it. – Rashad Novruzov Feb 18 '20 at 15:17
  • I think you misunderstood that part. The secretkey is not transmitted during API signing, but before. From the AWS Cognito server to the mobile app. – Martin Fürholz Feb 18 '20 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.