2

I'm working on an application that acts as a back end (REST API) for a Google Chrome extension. Data is supposed to be sent from and to the client.

The way it works is:

  • The data that comes from the client is encrypted by the application using AES-256 (using the master key, look below) and stored in a SQLite3 database.
  • The data that is sent by the application to the client is decrypted in the back end and then sent over an HTTP protocol.

Note, the application and the extension reside in the same local environment, thus other computers on the network can't access it. That's why the data is transferred in plain text in both cases.

There are a few constraints:

  • There can be a number of clients sending requests to the back end. They are all controlled by the same person.
  • There is a sign in form in the client and it only requires a master key. Once the form is submitted, the key is supposed to be sent to the back end and the client is authenticated, i.e. by comparing it to the one (encrypted using PBKDF2) in the database.

The Problem The problem is that I don't want to store the master key persistently in the client (Javascript), as it can easily be looked up by anyone else who can access the computer. If it was possible to authenticate only once, by sending the master key via the protocol to the application and then remove the key from the client.

So the question is what would be the optimal solution?

  • simple: you have the user enter the password at start, then pass around tokens thereafter. This allows safe password managers to manage the password instead of storing as plain text in localStorage. – dandavis Jan 19 '18 at 19:25
1

Is there any way to authenticate a HTTP client only once?

No, because HTTP is stateless.

data that comes from the client is encrypted...using the master key

Both the content in the browser, and the stuff on the server is the application. Where is encryption happening?

The data that is sent by the application to the client is decrypted in the back end and then sent over an HTTP protocol

OK, so when you say application you really mean the server-side?

It would appear there is never any requirement to store the "master-key" on the client.

sign in form in the client and it only requires a master key

You use the encryption key as an authentication token as well? Really? You expect users to type in something like

c48bb691eb5e2f609192ed5a981c6f8745896aa968604c1cdf70cb57ebc0d421

every time they log in? I'll bet you're either allowing them to pick really simple passwords/keys or they are storing them somewhere.

You could simply store the master key server-side in a HTTP session variable. But if this really is a "master" key, then the clients/users should have no visibility of it. You need to separate the authentication from the encryption.

There are various things you could do with local storage, a second server, encrypting the master key with the user's password to protect it, but without knowing a lot more about the platform it is impossible to advise (and becomes too complex for a discussion here).

0

i.e. by comparing it to the one in the database.

...

The problem is that I don't want to store the master key persistently in the client (Javascript), as it can easily be looked up by anyone else who can access the computer.

Given that you've established that:

  1. The master key is stored in the database.
  2. The database resides on the same computer as the client.
  3. You're worried about local attackers with access to the computer.

You've already lost. The master key can be stolen from the database. I'm not sure why you're convinced that storing it in e.g., LocalStorage is less secure than the database.

Defending against an attacker with physical access who can run code on your machine (which is what "anyone else who can access the computer" sounds like to me) is basically impossible. The best you can get is separate local user accounts with some kind of per-user encryption to protect the data, using keys backed by the TPM, and a Secure Boot environment, but you've suddenly gone from building a Chrome extension to needing to secure the entire environment.

  • I just realized I forgot to mention that the master key in the database is encrypted using PBKDF2. So, even though the potential attacker can access the database and steal it, they couldn't figure out what the key is. Am I wrong? – Andrius Jan 19 '18 at 16:28
  • Andrius, they could sitll mount a dictionary attack or similar, but they could not directly recover the master key. Obviously parts of my answer don't apply now that I know that, I'll try to update. :) – David Jan 19 '18 at 16:40

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.