2

I have system X from another department in our company that sends basic user info (not passwords) to my system using RESTful API. Both systems are using subdomains of the same domain but reside on different servers/networks. I just want to confirm that the incoming API request to my system is validated as coming from system X.

In almost all of the articles/questions I've run across talk about user credentials auth, but these don't apply to my situation because I don't want to push creds across for each request/response.

Is there/what would be a good secure method to achieve this handshake without user/pass/oauth?

  • 1
    "Decrypt the token..." - You said it's a hash, hashes can't be decrypted. Why not just send the secret? – AndrolGenhald Oct 2 '17 at 18:14
  • Right... I'm new to the security/auth field so still learning here. Thanks for pointing it out. Edited the question. – longboardnode Oct 2 '17 at 18:48
  • Kerberos authentication? – Daniel Grover Oct 2 '17 at 19:24
  • Is all of the traffic coming from system X coming directly from a web server? Does your organization own the web server? Can the traffic from system X make it to your web server unmolested by a proxy? If so, the simplest solution may be have the http server itself use SSL with client-certificate authentication. – user52472 Oct 2 '17 at 20:09
  • @user52472 System X is hosted externally so all traffic will come directly from a web server and server is not owned by us. But both System X and my system share the same SSL certificate (for the top domain) and I could potentially request System X to install an additional client certificate. – longboardnode Oct 2 '17 at 20:24
1

Here are my "off the top of my head answers", which may change after I give it more thought.

1) I'm not sure if there is much point to a salt here. In normal usage a salt protects a leaked password database against rainbow attacks. That certainly isn't relevant here, and moreover I don't think there is any other reason for the salt.

2) Hashing also doesn't add a whole lot of security, I think. Hashing is used to hide a secret during storage, not transit. If you hash it and pass along the hash, then that means your hash effectively is your secret, and a stolen hash is no less dangerous than a stolen secret. Therefore, in a very real sense, you might as well just send the secret itself, especially since it will change regularly.

In summary, you effectively have two defenses in place: a shared secret (which changes), and IP white-listing. Your shared secret is going to be primarily vulnerable to things like replay attacks or request eaves-dropping: if anyone happens to see it in transit, they will know the secret until it next changes. You mentioned this is system-to-system, so depending on whether or not your systems are in the same security zone will probably determine whether or not such a request needs to happen over TLS/SSL. If these systems are communicating between data-centers, you'll probably want to be communicating exclusively over TLS/SSL.

Your second level of security is via IP white-listing. This is primarily vulnerable to IP spoofing, which, depending on your network setup, may or may not be be an issue. I'm sure there are more options as well, but I'm not a network expert.

For a completely different approach you can try implementing a handshake. The basic idea is that when server A sends a request to server B, server B validates the request by contacting server A directly, passing it the full request that it received, and getting back a YES/NO response (the "no" obviously being returned if server A did not send the request in question). Only once it receives the "YES" does it actually process the request. This takes more effort to setup and also takes more network/server resources, so may not be preferable depending on your application needs. The advantage is that it rules out IP spoofing, and also makes the secret exchange unnecessary. However, it may not prevent more direct network attacks (i.e. MITM and the like).

Edit to add:

The handshake idea isn't actually my own. I've used that general flow in my applications to validate server-to-server notifications. The idea itself I stole from paypal (it is how they validate their IPNs), although it probably isn't originally their idea either. I point this out simply because it is a practice that has been in use for a long time, so you can both read their documentation to understand the flow and (potentially) look for information about past security issues that may have arisen due to that flow. Presumably though, since paypal relies on it for a critical part of their payment infrastructure, it is fairly secure:

https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNImplementation/

  • Thanks for the great reply. I get your point about the hash/secret not really helping here. Your handshake suggestion seems like it could work, I will look more into it. – longboardnode Oct 2 '17 at 18:54
  • Ok I think I see where my question went wrong... I should have asked, WHAT is a secure method to handshake the two systems. I edited the question but if you think I'm still way off please comment. – longboardnode Oct 2 '17 at 19:18
  • 1
    I think a good way to approach a question like this is to say "this is what I'm doing now, does it work or is there a better way?". It never hurts to start with what you got and make it clear that you're up for any suggestions people might have. – Conor Mancone Oct 2 '17 at 20:27
  • @longboardnode If you are interested in the handshake transaction, I've just posted some more details it. – Conor Mancone Oct 2 '17 at 20:31
  • Thanks Conor! You mentioned MITM attacks, any way to prevent/mitigate if I were to replicate a handshake in this scenario? Is verifying the SSL signature matches the origin of the request a good path? – longboardnode Oct 2 '17 at 21:15

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.