6

I am looking to build a number of simple REST web services where:

  • they only need to be called by server-side clients (i.e. no mobile/javascript/desktop)
  • they are only accessible by HTTPS (no downgrade to HTTP)
  • clients will only be deployed to secure, trusted locations
  • clients will each have a unique API key
  • each service will hold a list of permitted client keys

When accessing a web service, a client will provide it's unique client key in each request body for authentication to that service.

Question: Is this simple approach sufficient to restrict access to the services to only known clients?

rogersillito
  • 163
  • 1
  • 4

1 Answers1

5

So in principal if you have a situation where it's server-to-server communication then some of the standard concerns about user authentication aren't in play and what you've got sounds reasonable, some things to think about though (and whether these are relvant will depend a lot on your threat model)

  • Do the API keys used have sufficient entropy to prevent guessing or brute-forcing attacks?
  • Do you have a process in place for key revokation/re-issue in the event that one of the clients security is compromised.
  • Are you using Certificate pinning or something similar to mitigate the risks of client machines suffering a MITM attack, where the attacker has the ability to issue a cert from a "trusted" CA.
  • Does the process for loading the keys onto the clients and servers mitigate the risk of a participant in the process copying/abusing the key?
  • How are you storing the keys server-side? In the clear, in reversibly encrypted format, or in a hashed format?
Rory McCune
  • 61,541
  • 14
  • 140
  • 221
  • Some useful things to follow up there thanks: I've looked up [certificate pinning](http://security.stackexchange.com/questions/29988/what-is-certificate-pinning), which was new to me. – rogersillito Apr 03 '14 at 09:07