0

One of our security mandates require authentication between servers when transmitting data. These API endpoints are only accessible within the internal network and are never exposed.

Our idea is to user a single token authentication scheme. We will have a token pair between the internal servers and with each request, the calling server will submit the token in the request header over HTTPS to the target server. The target server will authenticate the token to see if it matches and if does, it processes the request. If it doesn't, it logs the invalid connection attempt.

We feel implementing OAUTH 2.0 or similar would be overkill seeing as its internal, we control both servers, there is a small group of people with access and it will be over HTTPS.

Is this an acceptable solution? The token will be generated using a secure random function and stored on each server with access right locked down. The token won't expire as it's not meant for users but for the servers.

Improve this question
4
  • You could do this...but is not IP whitelisting easier? Commented Jul 5, 2018 at 10:09
  • 1
    IP Whitelisting is not Authentication Commented Jul 5, 2018 at 13:34
  • Have you considered IPsec? Commented Jul 5, 2018 at 18:50
  • IPSec would limit network access, but similar to IP whitelisting it is still not application auth because it is transparent to the application layer. Just as an example, if an attacker gained unprivileged access to one of the servers they would proxy without any kind of login credentials for the targeted API. Commented Jul 7, 2018 at 12:28

2 Answers 2

Reset to default
1

What's acceptable to you should depends on the value of whatever you are protecting, and the risks inherent in other aspects of the system.

In many cases, your suggestion may be perfectly reasonable, but in others it may be unacceptable. Risk may be represented by consequences of a breach, times it's probability.

So if you are handling very sensitive information, but there is a very low chance that someone would get ahold of that shared secret, because you have very rigorous controls over who could gain access to it... you may be ok. But if your controls over the system are pretty lax, the probability would be higher and may be unacceptable. You could address that either with a different authentication scheme, or by reducing the chances that someone would get that token.

Some further suggestions to mitigate risks surrounding this type of authenticator:

  • Make the shared secret a setting, not a hard-coded string
  • Don't check it into source control
  • Make it easy to change in case of a breach (possibly have a grace period where two tokens are valid so that you can roll over without interruption)
  • Ensure the place where the secret is stored has correct file permissions locally, or you may use a service like Azure KeyVault Secrets so that the machine only ever has it in memory
  • Use a cryptographic scheme like HMAC to sign some detail of the request parameters, so that the actual secret is never passed over the connection. Azure Storage Accounts and S3 both work this way.
  • Also in the crypto camp, you could use TOTP, which combines a shared secret with a time-based hash; each token transmitted over the wire would be valid for a very short time, but the secret would never change
  • Pair the token with the IP address of the server that is allowed to use it, thus limiting it's use to the server it belongs to
Improve this answer
2
  • These are some excellent points, thank you for that. I feel our risk is low due to others factors, as in limited amount of people with access to both the token and servers. But the points about HMAC, file permissions I already was planning on addressing, I haven't considered TOTP. This is something I will definitely look into. Commented Jul 5, 2018 at 14:37
  • TOTP is HMAC underneath. I think it might solve the problem of “what to sign” for you, though. There’s also lots of TOTP libraries out there to help you get set up. Commented Jul 5, 2018 at 14:41
0

Since you're already using HTTPS you're already getting X.509 TLS server certificates. I'd suggest to use TLS client certificate for client authentication. This authentication mechanism is supported by most web servers out of the box.

Of course you have to renew the client certificates. But that's the same procedure like renewing server certificates.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.