I am looking for a relatively simple (for the client to consume) but highly secure method for user authentication on my API. By secure I mean strong authentication. The API to be built will be RESTful and as such inherently stateless.

I do not want to use basic HTTP auth as the key must be passed in each API call. Even though the API will only be available over HTTPS there is always the possibility of a MITM attack due to the client trusting a malicious CA. Rather a long shot, but I'd like to do this right to protect the data being transmitted.

My proposal is to generate a key pair, give the private key to the client and hold the public and a finger print of the private key. The body of the API call would be encrypted with the private key and the finger print would be sent.

The server would then look up the fingerprint, match it to an account, retrieve the public key and attempt decryption. If it fails then it acts as though the user is not who they say they are (as indicated by the finger print).

  1. Is my design secure?
  2. Are there better alternatives?
  3. Any advice/guidance would be greatly appreciated.

Client certificates are an established method which offer already what you need so that you don't need to invent your own. The process is even simpler than your version because you can just use existing libraries. The basic idea of having a key pair for the client is the same:

  • You create a certificate for the client or the client creates one itself. This certificate is either explicitly trusted by the server or implicitly because it was signed by the servers certificate authority (CA).
  • In the TLS handshake the server requests the certificate from the client. It checks if the certificate is a known and trusted one. If not the connection fails.
  • That's all.

It is impossible for a man in middle to actively intercept this connection by using a malicious CA because the man in the middle would need to rewrite both the server and client certificate. While you might not be able to control if the client trusts this malicious CA you can make sure that the server only trusts the known certificate or the certificates issued by the servers CA. This means an attacker can not fake the client certificate in a way that the server trusts it.

  • My apologies I am confused by your answer. From what you are saying it sounds like you think I am trying to prove to the client that the server is who it says it is. I am trying to do the opposite, the certs are given and the fingerprint pinned to each user to assert the client is who they say they are. I am not trying to reinvent the TLS wheel. My authentication model would sit atop of the TLS layer, and the reasoning behind my design was to avoid a handshake as there will be millions of requests to the API (in theory) So I am trying to balance speed and security. – sousdev Feb 11 '17 at 16:48
  • @sousdev: the motivation according to your question is security against interception even if the client trusts a malicious CA. Your question contains nothing about saving overhead or similar. And client certificates prove to the server that the client is the right one as much as server certificates prove to the client that the server is the right one. What I describe here is also called mutual authentication. If you need speed and small overhead this is possible too since you first can do multiple requests inside a single TLS connection and can also use TLS session resumption. – Steffen Ullrich Feb 11 '17 at 17:05
  • I understand what you are saying, I think I am having trouble conveying my meaning. Thank you for your help. – sousdev Feb 11 '17 at 19:00
  • @sousdev: maybe you should change your question then. Right now it says that you are looking for a "... highly secure method for user authentication on my API...". And that's exactly what client certificates are - secure authentication of the client using a key pair. – Steffen Ullrich Feb 11 '17 at 19:16

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.