Is secure sessional storage possible in MV3?

[Sonny Chee]

Hey Guys,

So I've invested some time  into building a password manager in MV2. Given that MV3 requires the use of the storage api, does that mean that my user data will be unsecured? I want the user data securely available throughout a session but there is no need to persist the data once the user closes the browser or "logs-out".

Any suggestions would be greatly appreciated.

[Simeon Vincent]

Given that MV3 requires the use of the storage api, does that mean that my user data will be unsecured

This question appears to be based on two assumptions that are not necessarily true. First, Manifest V3 does not require that developers use chrome.storage to store data. IndexedDB is available within service workers and the Web Storage API is available in other contexts. Second, using the extension platform's storage API is less secure than web APIs or storing values in memory.

Chrome's thread model does not take physically-local attacks into account (source). As such, if someone has physical access to a user's computer, values can be extracted from chrome.storage, LocalStorage, or IndexedDB with roughly the same level of effort, and values can be extracted from memory with a bit more effort.

I am not a security expert or a password manager developer, but I believe the current best practice in this space is to store sensitive user data (typically a password vault) encrypted when written to disk. Otherwise, sensitive data should only be held in memory unencrypted and even then it should be cleared out after a period of inactivity or when the user explicitly locks their vault. 

If you're concerned about accessing values across service worker restarts, you'll likely want to experiment with chrome.storage.session. This is an in-memory storage area that can hold 1MB of data. Data will be cleared when the user's browser session is terminated. Be aware that this storage area isn't appearing in the Storage API documentation at the moment due to a bug, but chrome.storage.session is available in the current stable release of Chrome.

Simeon - @dotproto

Chrome Extensions DevRel

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/31e96313-dc4f-4c22-9ab3-cef655ca45aen%40chromium.org.

[Sonny Chee]

Thank you for the detailed and helpful response Simeon.  

[Cuyler Stuwe]

Hopefully that arbitrary and incredibly-tiny 1MB limit is lifted, because it makes it incredibly awkward (as someone being paid for writing password managers) to write a password manager.

If your password manager had any legacy formats/architecture prior to MV3 (especially if you allowed associating arbitrary metadata per-credential, e.g., files, like 1Password lets you do), you have to do all sorts of arbitrary bug-prone code-fu just to manage this area. And you still can't actually assure the user that they will be able to reasonably store all of their credentials; At my company, the 1MB limit gives us a cap of somewhere between 1000-5000 credentials. I know of users (e.g., some who sit on the board of multiple companies) who very reasonably want to store more than 1MB will reasonably allow us to save.

It would be nice if we could at least get as much RAM as the New Tab Page (which holds 40x the maximum session storage limit, at ~40MB RAM used).