1

I'm making an API for my own software. The API currently used for registering users, viewing users information and updating users information.

In the future it will be used for billing, support etc ...

The API is currently visible online, it's only security currently is that to view or update a users information you need to know their unique ID which is a random number between 1 Billion and 2 Billion.

The only client for my API will be my own front-end that I'm yet to write.

I read about HMAC and OAuth and both solutions seemed extremely complicated.

Here are my current ideas to keep my API secure:

 1. Use HTTPS for all requests.
 2. Don't tell anyone the address of the API (I know I probably shouldn't rely on this)
 3. Send an access key and a secret key to the API and the 
    API sends back a token that is valid for 1 hour. (Maybe less)

Would the access key, secret key and HTTPS be sufficient to secure my API?

  • 7
    If you think OAuth is complicated, please pause for a little, study OAuth and HMAC in detail, and only after that you should resume planning. You will not be able to secure a public facing API without knowing a lot about security, and this site will not be able to provide you the knowledge you will need. And HMAC is simpler to implement. – ThoriumBR Jul 7 '16 at 19:40
  • 3
    Just so you know AT&T used a similar approach as your current idea. And they got breached. – Bacon Brad Jul 7 '16 at 20:24
  • 1
    What language is the API written in? Are you using a framework? Many systems come with pre-built authentication//authorization solutions that you could just leverage – Neil Smithline Jul 7 '16 at 20:38
  • 4
    Have you considered TLS mutual authentication? Your TLS framework probably supports it so you'll get it for free. Even HTTP basic authentication over TLS is pretty secure and requires virtually no implementation effort. I really prefer going with a well-established and tested strategy over a home-grown solution – Neil Smithline Jul 7 '16 at 20:50
  • 4
    an api is just a funny looking website, do the same thing you would to protect an http website. – dandavis Jul 7 '16 at 22:51
1

Quick answer - its not at all adequate to secure your API. Each of those steps has weaknesses which putting them together has not fixed. Good crypto is hard, and try very hard not to reinvent the wheel.

Https - will prevent the exact calls being visible in transit. But not at the user end, or to a "man in the middle" attack.

Hide a number - look up "security by obscurity". Tl;Dr do not rely on this. Ever.

Pass a token good for an hour - looks open to every form of authentication stealing and interception on the planet. How do you know that the token isn't being misused or used by anything except the intended client? You don't.

  • well... lots of websites work like that: API Tokens that are valid until revoked. Stealing a token isn't harder than stealing a password because those two things are essentially the same things. – mroman Sep 10 '16 at 18:48
1
  1. Harder to implement, more work.

  2. Clients can simply go into Chrome developer tools and go under Network to see where the request are being sent.

This is what i do to secure my api. I build with a MEAN stack and i used JSON Web Tokens. I use a library called passport.js to authenticate. This is how i protect:

Lets say i have an api route as such:

UserRoutes.post('/message', Middleware.verifyToken, function(req, res) {
      //post message and save to DB
});

Notice i used Middleware.verifyToken above in the "middle". This is called from the class below

Then i have a file somewhere else called Middleware.js and inside a method:

verifyToken: function() {

//grabs the json web token from the authorization header and verifies its valid. //If it is valid then continue will the route logic

}

So these are the steps:

  1. Assign an user a Json Web Token when they log in(i store mine in LocalStorage)(i used the libraries: jsonwebtoken, passport-jwt, passport, bcrypt).
  2. Implement a middleware function that will verify the token. This will make sure token/user is valid before the actual logic of the route is executed.

Overall concept is that the user must present a valid json web token with every request, and this token is checked before the route logic is executed. If it is not valid or does not exist then the route will not execute and you can return a error to whoever made the request.

Took me about a month or two to be able to fully implement this system because took me a while to learn and understand passport.js and middleware but once i did it was great and is definitely worth the time it takes to learn.

Research: Middleware, Json Web Tokens and Passport.js

https://jwt.io
http://passportjs.org/

1

My analysis:

  1. Use HTTPS for all requests.
  2. Don't tell anyone the address of the API (I know I probably shouldn't rely on this)
  3. Send an access key and a secret key to the API and the API sends back a token that is valid for 1 hour. (Maybe less)
  1. You need to activate an HSTS header to truly ensure you're using HTTPS for all requests
  2. Security through obscurity. Why not just put a password on it? Note: make sure you store the password securely using bcrypt and a salt. Here's an excellent explanation by Tom Scott. Anybody can see the URL by opening developer tools and going to requests.
  3. Possibly secure, depending on how you implement it. Don't try to implement your own cryptographic suite. It's a really bad idea.

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.