3

We are currently designing a REST API, and thinking about securing it.
Going through a lot of documentation, it has become clear that 2 options are available.

HMAC Authentication

By hashing with HMAC-sha1 a series of predefined elements with the secret_key, we sign the request. The verification is done by doing the exact same process server side and comparing the resulting hashes.

Our implementation goes like this:

  • Getting current timestamp
  • Creating HMAC: hmac(full_url + request_body + timestamp + secret_key + token)
  • Sending the signature as it: clientId + hmac_signature + timestamp + token

The main advantage of this, is that the secret_key is never transmitted in the request, which prevents replay attacks mostly. But as a drawback we have to store the client credentials (secret_key) in a raw format in our database. And if our database gets compromised we might as well revoke all current API clients credentials.

HTTPS Authentication

Using SSL over our API will allow us to create a secure channel to exchange private information.
We basically send the same information without hashing it with HMAC.

Our design is going to be exactly like (or very similar to) the OAuth2 specification.

Comparing to HMAC this has many advantages as we delegate most of the job to SSL. And clients do not have to include a library for hashing like with HMAC. Finally our database is safe since client's secret_key will be securely stored.

But if someone successfully sniffs out one request, he could steal the secret_key and start to create his own requests.

Is there a way to use the advantages of HTTPS without sending clear credentials and without having to store clear credentials?

One of our alternative designs was using private/public key generated client side, and use it to exchange a key to encrypt secret_key for future requests. But not many browsers have this capability (<keygen>) and it is quite an annoyance for mobile applications.

Improve this question
7
  • 1
    https will not send clear credentials. how will someone sniff one https request to get key?
    – mcgyver5
    Commented Jul 13, 2015 at 15:05
  • Credentials will be sent in clear through the ssl connection. Maybe this is a misunderstanding from myself, but doesn't this makes it vulnerable if someone use mitm attack ?
    – Cyrbil
    Commented Jul 13, 2015 at 15:10
  • 1
    part of the purpose of ssl/tls (https) is to not send credentials in the clear. When working, it defeats mitm.
    – mcgyver5
    Commented Jul 13, 2015 at 15:13
  • 1
    What you are missing is that the client-to-server HTTPS connection will have to terminate at the proxy and the proxy will then have to create a new HTTPS connection to the server. Both the client and the server will be aware of this and as long as you have configured the client and server correctly (default for most systems) the client will protest because the endpoint (proxy) will not match the device registered to the SSL certificate identifying the server.
    – David Scholefield
    Commented Jul 13, 2015 at 16:42
  • 1
    @DavidScholefield One catch or exception is that if you are on a workplace computer and your IT department has enabled SSL inspection in your firewall, and installed the certificate from the firewall into the certificate stores on all the workstations (using Group Policy or some other method), the client will accept the proxied connections without protesting, and the firewall can indeed then intercept and log the cleartext of your HTTPS session.
    – Craig Tullis
    Commented Jul 13, 2015 at 19:52

1 Answer 1

Reset to default
3

As pointed out in the comments, ssl/tls will protect your credentials in transit. Encrypting traffic is part of the purpose of the protocol. The other major purpose of the protocol: verifying that you are communicating directly with the party you think you are communicating with.

The OP said that ssl proxies are possible and has seen it in action for mobile applications.
It is true that ssl man-in-the-middle proxies exist, but the client will warn that the server it is talking to has failed to present a valid certificate (and if the client is a browser, not proceed).

If your Rest API is configured to ignore bad SSL certificates (and some are - i know, I've written one), then, yes, a ssl MITM proxy would indeed be able to sniff your credentials. This is purposely subverting the SSL/TLS protocol (you can't say you are using SSL/TLS in this case).
This is why "self-signed" certificates are only for development and testing purposes.

Improve this answer
2
  • SSL/TLS will protect your credentials in transit with one or two minor exceptions, such as a workplace installing a root certificate off of an SSL-inspecting firewall into the certificate store on all of their workstations (on all machines joined to an Active Directory domain, for instance).
    – Craig Tullis
    Commented Jul 13, 2015 at 20:50
  • Yup. There are ways to subvert the protocol. Rogue certificate authorities (phreedom.org/research/rogue-ca) are another.
    – mcgyver5
    Commented Jul 18, 2015 at 20:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .