4

I'm creating a self hosted application which relies on CouchDB to store its data. The client (react) might access the database, which is proxied by the express server to myapp.com/database. The server needs to access the database as well. Here is what I can think of for the first start process:

  • Create databases
  • Generate a random JWT secret and save it somewhere
  • Create validators functions for data and permissions
  • End admin party by creating an admin account (credentials randomly generated and saved somewhere with secret)4

When starting the app:

  • remove from _users all end_users
  • generate a instance UUID and save it to memory.

user signup process (which might only happen once or twice on a server):

  1. In the client, send a request PUT /api/users with username and password
  2. When receiving this request, server generates a secure hash and salt using password-hash-and-salt and then save it into app_users (a collection only accessible by admin user - controlled by node app)

Basic login process

  1. In the client, send a request PUT /api/sessions
  2. In the server, when receiving the request, create a new _users with a randomly generated password with role end_user and as _id users/:uid/:username (with as uid the UUID generated when starting server)
  3. Save the generated password to memory
  4. Still in the server, sign a 1w JWT that includes the username and the instance ID and return it to the client
  5. Timeout in 1 week a database removal of the created _user.

Basic database operation:

  1. In the client send a request to /database/posts (for instance), with in the headers the session token
  2. In the server intercept the request, read the session header, verify it, and then get the database saved in (3) of login. Replace the Authorization header with a Base64 encoded password:username.
  3. If the user bears no valid token, do not proxy but return 401.

This process allows several things:

  • Make sure the client never knows any database password
  • The couchDB client would send in the header a Base64 encode of the username/password. This avoids that the password/username is sent on every request and thus reduces a potential attack surface.
  • This allows to create custom session policies like 1w expiration or possibly password rules (like minimum entropy)
  • The client doesn't need to store in memory the password for long.

How secure would this authentication flow be?

2
  • way too much to go over here, got a specific question on a certain aspect?
    – dandavis
    May 5, 2017 at 0:58
  • Well, it's about the whole process, so I find difficult to reduce the content
    – Vinz243
    May 5, 2017 at 9:07

1 Answer 1

0

An issue considering your flow is the use of Base64 encoded credentials over the network, which are always vulnerable to eavedroping.

A first fix for this issue would be to enforce TLS with a secured ciphersuite. SSL/TLS Encryption is now supported since CouchDB 3.0. It is much better to get rid of the unsecured Basic HTTP URI authentication that couchDB used to use by default (http://user:[email protected]).

You must log in to answer this question.

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