Hash a secret API key with a random salt instead of sending sending it alone in REST API

Question

Say, I have an internal https API endpoint used only by me being the admin. In each each request I send a secret API key for authentication. And I'm fine with this solution.

  curl -x PUT .......
  --header "X-My-Secret-Api-Key $my_secret_key"
  .....

In the body I send user's id and email as the payload.

Will it be more secure if I hash $my_secret_key with user's email?

  curl -x PUT .......
  --header "X-My-Secret-Api-Key SHA-256(${user_email}${my_secret_key})"
  .....

The idea is that even if "X-My-Secret-Api-Key" gets intercepted, an attacker then will get the secret key only for that particular user. And will be able to send malisicous requests on behalf on that user only and nobody else's.

And to be able to send requests on behalf on another user, an attacker will have to try to intercept "X-My-Secret-Api-Key" for that user also. And so on.

Is this a decent security improvement? Any downsides? Is this a known technique?

Answer 1

It is a good idea to move in the direction of least privilege authorization, so if use of an admin API involves impersonating specific users, there should be a credential that represents the specific user under impersonation.

That said, I would encourage consideration of practices other than taking a permanent admin key and hashing it with a permanent public user attribute to produce a user-specific credential. The most important weakness of that user-specific credential is that it is permanent.

Consider moving in the direction where individual actions are granted specific temporary credentials, so one is not doing any actual business with an admin key. So: create an API that takes the admin key and an action- like impersonate a user, though actions can include admin actions that are not user specific as well- and create a temporary token with only those privileges. Require the use of those limited privilege tokens and disallow the use of full-privilege admin key in any specific privileged operation.

There is of course a lot of prior art here, and lots of specific considerations that apply to specific situations, which one may or may not be inclined to dive into. Generally speaking, though, moving in the direction of the use of temporary credentials is better than constraining permanent credentials.

In sum:

Is this a known technique?

Yes, there are many ways to constrain a token for use in a specific circumstance. Can add the email address as another header and hash the secret/email pair. See also JWTs. Many, many permutations to achieve similar ends.

Is this a decent security improvement? 

It is better to use a token with fewer capabilities than one with more, so, it represents an improvement, but as below, there are much better improvements, so while it is an improvement, it's not a decent improvement.

Any downsides? 

The permanent nature of the tokens is undesirable. Someone who gets one user's token can presumably get other user tokens, and since they are based on permanent attributes- a permanent secret and the user email- they can be used by the attacker forever. Better to move in the direction of adopting time-limited tokens, which can also be constrained to permit only specific functions.