1

I am working on a project where two parties can each make API requests to each other and are authenticating using a shared secret. The other party wants the shared secret to be the same both ways, but I don't understand how that would work. So I'm either looking for an explanation of how to do this securely, or to find out if this is not something that is possible and that the shared secrets should be different based on the direction of the request.

If the API request were just going in one direction, I would salt the password using a key defined function, and store the hash and salt, then I can authenticate the user by generating and matching the hash on each request. But if I need to use that same shared secret to make requests to the other API, then it seems like I would need to store the password in a way that it can be decrypted, which seems wrong/not possible.

Is there a way of doing this, or should the shared secret be different depending on which direction the request is going?

Aaron Z
  • 11
  • 1

1 Answers1

0

Your analysis is correct. If both side can be the caller, then both sides need to know the secret (not just be able to verify it).

Having two separate keys (one for each caller, you might as well call them "passwords" in this use case) seems to be a reasonable default setup.

It is always good to think of "parties" and give each their own credentials, especially if more parties will be involved later. Makes it much easier to revoke individual access rights later on, to enforce fine-grained access control, and minimizes the impact of leaked credentials (an attacker can only impersonate that one party, not anyone else in the system).

Having just one may appear slightly easier to manage, but then you become responsible for not leaking the other guy's key (in addition to your own). I would try to avoid that extra burden.

Thilo
  • 257,207
  • 101
  • 511
  • 656