Is HTML5 sessionStorage secure for temporarily storing a cryptographic key?

Question

Assume I am building a local web application (e.g. browser extension) in HTML5 to encrypt a database locally. Access to the database is controlled by a password and a cryptographic master key is derived from the password using a PBKDF. I want to store the derived master key in memory only while the application is in use so I can encrypt and decrypt records as needed.

I have looked at using sessionStorage for this purpose. The advantage is the key should only be in memory and available to the current browser tab. The key should be deleted if that tab or the browser is closed. The advantage is that if you need to refresh the browser tab it will still have the active session and master key otherwise you would need to re-enter the password each refresh. Refreshing may be a rare occurrence as it is a single page app however.

On reading the sessionStorage specification on W3C there is some concern:

The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

Is this talking about an OS restart or browser restart?

What I absolutely want to avoid is having the cryptographic key written to disk where it is very hard to get rid of. Is the above quote saying there is a possibility that the key in the sessionStorage could be stored on the disk as part of the crash recovery/restart process? Or is this restart process usually handled in memory only?

a) Does anyone have any knowledge on how the Tier 1 open source browsers (Firefox, Chromium) handle the sessionStorage and whether the contents could be written to disk, even temporarily in the case of a browser crash?

b) Are there any mitigations to prevent any leak of the key to disk in a browser crash or restart? Are there any about:config settings that could be used to disable session recovery after a browser crash?

c) Is the safest option to not use sessionStorage at all for storing a key? Or perhaps mitigate the risk by using full disk encryption as well?

Thanks for your help.

Answer 1

In short; A browser restart. However, not every browser implements the specification defined by the W3C the same way.

a) Does anyone have any knowledge on how the Tier 1 open source browsers (Firefox, Chromium) handle the sessionStorage and whether the contents could be written to disk, even temporarily in the case of a browser crash?

It makes no mention of saving data that at the time resides in sessionStorage. You will need to research each browsers implementation to know for certain.

Please refer to Mozilla's documentation, there is also a bug/feature request to migrate this functionality to a sqlite database.

b) Are there any mitigations to prevent any leak of the key to disk in a browser crash or restart? Are there any about:config settings that could be used to disable session recovery after a browser crash?

While each browser's extension API is going to vary, each should implement some error handling, as well as event triggers in the event of a crash.

For example Google Chrome's documentation uses a crash event trigger that doesn't conform to the W3C Progress Events standard RFC documentation.

c) Is the safest option to not use sessionStorage at all for storing a key? Or perhaps mitigate the risk by using full disk encryption as well?

You shouldn't need to store the derived key, once records are decrypted and written to the DOM during a session the key should only need to persist until the session ends when encryption takes place. Use of sessionStorage is good for maintaining data within the DOM only while the tab/browser is open, hence the name 'session'.

With that said if your really in need of safe guards and feel full disk encryption would mitigate the issue, consider the following scenarios:

1. Access to the boot partition of a full disk encrypted machine would allow modification of the initramfs (linux installtion) allowing for a method of capturing the input supplied key used for disk encryption.
2. The transport used to get the web application to the clients browser if not wrapped in an encrypted protocol such as TLS could allow for injection of malicious code able to capture keyboard input. See the BeEF injection toolkit.

I wrote this tool; secStore.js. It does what you are talking about accomplishing. Just make sure you wrap the transport layer with an encrypted tunnel, use security headers to mitigate XSS attempts and you can even query the loaded browser plugins/extensions to prevent malicious exploits using that avenue.

Hope that helps. Anything with security should be layered and it is almost impossible to cover every attack vector which is where monitoring comes in handy.

Answer 2

Apparently the sessionStorage is not really cleared when closing the tab. It is easily revived by clicking on "Reopen closed tab"

I've written more about it in here: http://blog.guya.net/2015/08/25/the-never-ending-browser-sessions/