Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two servers (one on Hetzner (I am calling it H) and other in my office (calling it O) ). I need to run a basic CRUD web service on O and the only consumer of the service is H. Data on O is sensitive user data. This is a temporary duct tape service which will go away in the future along with the need for the server O.

Here is what I have in mind:

  1. Service will run on https
  2. Basic HTTP auth for request authentication
  3. Opening the port on O only for H's ip via iptables.

I would like to know if it sounds secure enough or if there is anything I might have overlooked? Are there any advantages that HMAC or OAuth offer over this approach?

share|improve this question
up vote 12 down vote accepted

HMAC is a cryptographic algorithm which makes sense as part of bigger protocols; you should not fiddle with it directly. When you use HTTPS, the SSL layer actually includes some HMAC (among other algorithms).

OAuth is a standard for authorization whose main use case is managing authentication of users without sharing credentials -- the idea being that one user could have credentials (a big word for "password") known to a single server, that can be used to be granted access by several other servers without trusting them enough to show them the actual password. Say, servers S and T trust authentication server A, user U also trusts A enough to show it his password (within some HTTPS connection), and S and T talk to A to make sure that user U is indeed who he claims to be; the nice part is that S and T never see the password and U needs not trust them.

In your case, you have a single "user" (your server H) and since that's a machine, it needs not be picky about his password; H can have a "password" (a long sequence of random characters) which H will use only to authenticate with O, so there is no need for the extra complexity of OAuth.

The inherent vulnerability here is that server H has access to the sensitive data. That's by design, but this means that the data makes it to an hosted server, which implies that you trust the hosting service for not peeking at your data or leaking it through carelessness. You cannot evade that, as per your problem definition. You basically consider server H to be safe, by itself, from eavesdropping and hostile alterations. Under these conditions, HTTP's "Basic" authentication run within HTTPS will be fine.

You might want to tighten a bit server authentication: machine H will need to make sure that it talks to the genuine O server, which normally entails certificate validation. You can configure H to make "direct trust", i.e. import in H a copy of O's certificate (just the public certificate, not the private key), and instructing H to trust that specific certificate and none other. This may avoid issues with Certification Authorities, and, in particular, allows for safe usage of self-signed certificates, which are cheap (since you don't have to pay a CA for such a certificate).

share|improve this answer
Thanks for your input. By HMAC i meant this approach followed by AWS. – Abhinav Kaushik Jul 31 '13 at 7:11
Yep, H is the weak link in this scenario but I don't have any other option. I'll go ahead with HTTP basic auth running inside HTTPS. I'll also implement "direct trust". – Abhinav Kaushik Jul 31 '13 at 7:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.