To make the question clear: is the sentence below considered “safe”? (i.e. does not introduce significant security risks).
I don’t see a clear reason why the following sentence would be considered completely unsafe (for example, “don’t even worry”), which seems to be a quick response to something with the words “local storage” and “secure” in the header). Essentially, this is based on the premise that: either you have access to sensitive data in memory and cache, or you have access to it.
starting point
I have a web application that includes server-side web services and javascript running in a browser that calls these web services (securely, over HTTPS, this is not a problem) and displays the data on the web page. Let's say this is an email application that displays your emails - that is, data that you do not want to share with others.
A few points to note at this point:
- The user is authenticated with the server, and javascript running in the browser is able to call the server’s web services to retrieve the data.
- Javascript running in the browser also has access to the page, and all (sensitive) information is available for this javascript. Sensitive data is in-memory and available for javascript (yes, including any malicious javascript).
Until now, this is a standard web application, and I assume that any reading will be convenient, that it is considered "reasonably safe."
Adding a secure cache?
The problem is this: every time a user visits the site, their browser needs to download all (email) information, most of which will be the same every time. It would be nice if, instead of requesting a server for all the information each time, it can cache data in the browser and check the cache. Keep in mind that this is not “offline” access: the browser still speaks securely on the server, but it can use the data stored in the cache on the browser side rather than retrieving it from the server.
Here's the suggestion:
- When the browser retrieves data, it also retrieves a long, random, server-generated key. This key is stored securely on the server by the user.
- In the browser, this key is located next to sensitive data in javascript memory.
- The browser uses the key that it gave to the server and the accepted cryptographic algorithm (for example, SHA256), encrypts the data stored in memory and puts it in local storage.
- When the user closes the browser or moves away from the site or "logs out", the browser no longer displays confidential information, and the key also disappears with it.
The consequence is that after the page has disappeared (or very soon after that), the ability of the browser or any user with any level of access to it to decrypt the contents of the cache is local storage. For this, they will need a key: if they had a key , they would already have access to the data itself (in browser memory / javascript).
When the user later returns to the site, they need to authenticate with the server again in order to receive data through web services.
- At the same time, javascript retrieves the (same) key from the server, which it can now use to access the cache in local storage.
- Presumably, there may be a server process introducing a new key in time to avoid using the same key indefinitely.
Any thoughts?
What is it worth, remember that I read:
(so I at least know that problems around javascript + local memory + security)
source share