Securing REST API with HMAC and basic auth

Question

I was wondering if giving users choice of a method for securing their access to API would be a good idea.

Background:

We are creating and deploying applications for our customers, which help them do their work more efficiently. Each of our clients is running a self-contained application and we plan to create an API that will allow them to integrate their third party tools or what have you. It will not be a public API but a private one.

Now, when researching the subject I came into an understanding that using basic auth, even through HTTPS is not a very good idea. Apparently, preferred method would be using HMAC with nonces. I am all for securing the fort, however HMAC solution presents one problem - its more complicated and requires developer to firstly create HMAC and then feed it into a request, basically making whole API not easily discoverable (like you cant just type in curl https://my.url/api/endpoint/ and see what happens).

It cam to my attention that people at Stripe do use basic auth with token as a user so their curl request looks like this: curl -u sk_test_mysecretrandomkeywhatever https://my.url/api/endpoint/

This is my book is a big advantage and if its good enough for payment processing company then perhaps it will be good for us too?

Then I got thinking - what if we offer both as a choice? You want to use basic auth only? Fine, you can use only that. One of your clients is a security freak and wants to make sure that your system is secure? Enable HMAC authentication and start playing with HMACs etc. Is that a feasible solution or would you say it is a security travesty?

Please shed some light on the subject or at least point me in a right direction.

Answer 1

It is not clear for me which kind of problem you are trying to solve and it might not even be clear to you. If you have a clear idea what you are trying to achieve with the authentication than you would not need to offer the client multiple authentication schemes but stick with the one which solves your problem.

If you fear a compromise of the authentication credentials because the connection might be sniffed simply use TLS. In this case basic authentication, session cookies or similar "clear text" authentications offers enough protection since the secret is protected during transfer.

If TLS is not possible you might use challenge response methods where you have a pre-shared secret key. This protects the authentication but does not protect against hijacking of the connection, i.e. a man in the middle could pass the authentication and then modify any actions done inside the authenticated connection. With proper use of TLS this would not be a problem but then you could also use simpler authentication methods.

There are other authentication methods (like mutual TLS authentication) but I recommend you first determine what needs to protected and what kind of misuse you want to be protected against. Once this is done you can select from the existing methods the one which matches your problem best.

Answer 2

Well curl with basic authentication is acceptable - remember thought that the syntax is curl --user name:password https://yoursite.com and this means that you will have to hard code credentials in the code that invokes your REST API - typically if it's Ajax - then we're talking client side code and that means exposing credentials in the browser (or in a mobile app) which is a vulnerability.

I think that you can improve with a 2 step approach which is pretty common practice:

When user logs in (app or browser) - get username/password from a form and use curl with basic authentication to ask the server for a TOTP time based one time token. I don't know what language you're using but in Node JS there are libraries like this https://github.com/guyht/notp that are active and maintained projects.

If you are hosting on Azure you can use Azure SAS shared access which is part of the Azure infrastructure and save you code and test.

Answer 3

On second thought - a great way to authenticate an API that exposes your systems' functionality to partners is OAUTH2 - what is terrific about OAUTH2 is that you have a good choice of libraries, and you can use a flow that fits your user relationship - server flow, web browser flow, mobile flow, password flow without changing your underlying API business logic.