5

To make the question clear: is the proposal below considered 'secure'? (i.e. doesn't introduce any significant security risks).

I haven't seen any clear reason why the following proposal would be considered completely insecure (as in, 'don't even bother', which seems to be the quick answer to anything with the words 'local storage' and 'secure' in the title). Fundamentally, it's based on the premise that: either you have access to the sensitive data in memory AND the cache, or you have access to neither.

The Starting Point

I have a web application which includes server-side web services and javascript running in the browser which calls those web services (securely, over HTTPS, that's not the issue here) and displays the data in the web page. Let's say it's an email application that displays your emails - i.e. it's sensitive data that you don't want to share with others.

A couple of points to note at this stage:

  • The user has authenticated with the server and the javascript running in the browser is capable of calling the server's web services to the retrieve the data.
  • The javascript running in the browser also has access to the page and all of the (sensitive) information is available to that javascript. The sensitive data is 'in memory' and available to the javascript (yes, including any malicious injected javascript).

Up to this point, it's a standard web application, and I'm assuming that anybody reading would be comfortable that this is considered 'acceptably secure'.

Adding a Secure Cache?

The problem is: every time a user visits the site, their browser needs to download all of the (email) information, most of which is the same each time. Wouldn't it be nice if instead of needing to ask the server for all of the information each time, it could cache the data in the browser and check the cache. Bear in mind this is not 'offline' access: the browser is still talking securely to the server, but it may use data stored in a browser-side cache rather than retrieving it all from the server.

Here's the proposal:

  • When the browser retrieves the data, it also retrieves a long, random, server-generated key. This key is stored against the user, securely, on the server.
  • In the browser, this key sits alongside the sensitive data in javascript memory.
  • The browser uses the key it was given by the server and an accepted cryptographic algorithm (e.g. SHA256), encrypts the data it has in memory, and put it in local storage.
  • When the user closes the browser, or navigates away from the site, or 'logs out', the browser no longer displays the sensitive information, and the key is also lost alongside it.

  • The implication is that once the page is gone (or very shortly after), the ability for the browser, or anyone with any level of access to it, to decrypt the contents of the cache is local storage is gone. In order to do so, they would need the key: if they had the key, they would already have access to the data itself (in the browser/javascript memory).

  • When the user later returns to the site, they need to again authenticate with the server in order to retrieve data via the web services.

  • At the same time, the javascript retrieves the (same) key from the server, which it can now use to access the cache in local storage.
  • Presumably, there could be a process of the server introducing a new key over time in order to avoid the same key being used indefinitely.

Any thoughts?

For what it's worth, bear in mind that I have read:

(so I'm at least aware that the concerns around javascript + local storage + security)

Community
  • 1
  • 1
decates
  • 3,406
  • 1
  • 22
  • 25
  • Using the browser cache will most likely not work when your pages are using HTTPS, because there are browsers that don’t cache HTTPS resources per default. – CBroe Jan 21 '14 at 09:51
  • Makes sense, @CBroe. There's no suggestion of using the browser cache (aka 'temporary internet files', etc.) as this would involve the raw, sensitive data being stored on disk in a non-encrypted form, which is not acceptable. – decates Jan 21 '14 at 12:05

1 Answers1

0

Security and cryptography is a environment where specifics really do matter and be aware that you've been very vague. Implementation is very easy to get wrong. If this is in a commercial application and data sensitive enough consider professional help.

However if you're going to try, ensure you're using a secure encryption cipher to encrypt your data otherwise you're going to open yourself up to attacks specific to your encryption method. Remembering that defaults are set for simplicity, not security. (Eg. ECB mode in block ciphers)

I would never recommend encrypting 2 identical texts with different encryption keys. Consider interlacing random text to make them not-identicle

Here are some attacks that systems like yours are generally vulnerable to:

  • Chosen-ciphertext attack
  • Known-plaintext attack
  • Random number generator attack
  • Ciphertext to plaintext length correlation

You'll also want to ensure that this encryption key is not vulnerable to XSS and other standard internet attacks.