Securing a private API that's visible on the public Internet

Question

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?

Answer 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.

Answer 2

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/

Answer 3

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.