security - access token best practises

Question

I'm currently working on a simple API that's going to be the backend of my app. I'm designing my data structures right now and have some questions about security best practises.

Project background

The project is written in node.js

Since this is going to be an API (with a couple of protected methods) I think it's best to use an access token based authentication system. (user logs in and retrieves their token, which can then be used to access the protected methods)

The data is structured in such a way that every user has both a unique username and a unique token. For the purpose of this question (and my project) let's assume that this token never ever changes. However it is stored in plain text in the database.

To make sure that people with access to the database don't have direct access to the API by just copying this token I encode the token before I send it out. This way the actual authentication token is not the same as the token stored in the database but the server can decode the auth_token to recreate the token and blah blah..

However people with access to the database can just encode the token themselves... And I'm trying to find out if there's a workaround to this problem.

My question:

I'm trying to find out if there's an even safer way to do this. So please give me all of your ideas and best practise rules etc.

BTW, I considered using a salted hash as encryption but this creates the exact same problem, to match the stored token with the actual access token you'll need to also store the salt, since you can't revert an encryption like that. And storing the salt gives people with access to the database a way to create the actual access token...

---

PS: I'm trying to create the entire authentication process myself, so please don't suggest things like passport.js. I mean there are great helper tools out there, I just want to do this all manually.

[Update] project background

Down here I'll attempt to sketch some more background to this project. It is indeed a project for high school informatics. (as mentioned below) The idea is simple: a TODO app, you might have heard of node-todo, that's basically it.

This is a group assignment and the levels of expertise among the group members highly varies. (Some have only ever done HTML and (some) CSS, others have done some JS) I've taken the responsibility of creating the backside of the application (the API to interact with the database) since none of the other group members know how. Since the other group members are not all as experienced I have no clue what the front end is going to look like. (My best guess it'll start off a web app)

So basically I want to create a backend that works for every client, and it should be independent. That is, the client is not going to be hosted on the same server (most likely the test are going to be locally only).

API-oriented. Modern applications compose and expose APIs everywhere. They build on open web techniques and use REST, XML and JSON to make it easy for all types of devices and clients to easily consume data. Any visible service or piece of data has a "headless" API counterpart, so that alternative views can be provided. In many cases, the APIs that a modern application exposes form the basis for a public, 3rd party developer community that enables mash-ups, plug-ins and innovation on a core set of data and services that drive a company's business ~ zdnet.com

Answer 1

If you do not mind saving state on your server, you could use a hashtable to save tokens:

Once the user logs in, you generate a random hash. This hash is used as key in the table. You can verify incoming requests by validating that the used token is indeed a key in your table.

To be able to identify which user is logged in, you should add a user identifier (like user email) to the saved object. You might also want to add the used IP-address and an expiration date to this object to further improve security.

By using this technique, you do not need to save tokens in your database :) Only hashed passwords

(You might want to clean your hashtable now and again to delete expired entrees)

Good luck on your project and say hi to Ramon for me

Answer 2

I usually just use jwt with it's own salting process. I don't store the token at all in my db, but just use it to store the user's information and set an expiry of 8 hours or so.. This way, you don't need to store tokens in the db, you just decode the token on each request and access the userID stored within its payload. The only downside is if someone steals someone elses token, but you can add in an IP address to the payload and make sure the clients ip is the same as the one stored in the token.

I'm not using passport, but I am using bcrypt for password encrption and JWT for my tokens. Sorry if this isn't what your looking for. Cheers.

Here is my auth library:

(function() {
  var bcrypt = require('bcrypt-nodejs'),
    jwt = require('jsonwebtoken'),
    helpers = require('../lib/helpers.lib.js');

  var JWT_SECRET = 'XXXXX';

  module.exports = function() {
    var self = this;

    //Returns true if valid token given, false otherwise
    self.validToken = function(token) {
      if (token) {
        try {
          var decoded = jwt.verify(token, JWT_SECRET);
          return true;
        } catch (err) {
          // console.log(err)
          return false;
        }
      } else {
        return false;
      }
    };

    self.decodeToken = function(token) {
      if (!token) {
        return null;
      }
      try {
        var decoded = jwt.verify(token, JWT_SECRET);
        return decoded;
      } catch (err) {
        // console.log(err)
        if (err.name == "TokenExpiredError") {
          return 'expired';
        }
        return null;
      }
    };

    self.createToken = function(payload, expires) {
      options = { "expiresIn": ((expires) ? '2d' : '14d') };
      return jwt.sign(payload, JWT_SECRET, options);
    };

    self.hashPassword = function(password) {
      return bcrypt.hashSync(password)
    };

    self.comparePassword = function(plainTextPassword, hashedPassword) {
      return bcrypt.compareSync(plainTextPassword, hashedPassword);
    };

    return self;
  };
}());

Answer 3

multiple things come in mind: - have you looked at Firebase? - what about things like two factor authentication (e.g. speakeasy or authy)?

You do not give too many details on the project background, I understood from mr. Moorlag that it has to do with high school informatics. So in case you want to make a proof-of-concept (e.g. for a Profielwerkstuk (± high school thesis in Dutch schools)) you would have different requirements than 'just implementing an app' that you would want to publish in the Play / App Store of course.

Some minor students of mine did a workshop two weeks ago about Firebase and then you do not need to worry about such a things, works really great (note: Firebase is NoSQL so forget normalization ;)). If you want to do research on it I would find out the details about two factor authentication and also have a look at TLS / HTTPS (Let's Encrypt?! yay!).