Encrypted storage

[ghost]

IndexedDB is good but limited feature in security.

If possible, a minor API changes will allows developers to protect content in IndexedDB.
Browsers may choose to encrypt the actual content (or not).

In many traditional web app, login happens on server side and use Cache-control: no-cache, private to avoid protected information being leaked to cache or in a share machine environment.

I was thinking of few examples. e.g

indexedDB.open("protected-user1", {ttl: 3600, key: {simple: "simpleKey"}});

or

indexedDB.open("protected-user2", {ttl: 3600, key: {cookieName: "JSESSIONID"}});
// A traditional server side logout will flush the cookie. The DB should flush as if it depends cookie.

or

indexedDB.open("protected-user3", {ttl: 3600, key: {url: "http://example.com/mykey"}});
// where url must be in a trusted origin,
// server side may use any method to authenticate (e.g. IP whitelist or trusted HTTP2 tunnel)

[inexorabletash]

We are exploring cookie change events https://github.com/WICG/async-cookies-api as a more general solution to this, where cookies being revoked by expiry can invoke code.

Another approach is to encrypt data yourself and have the decryption key present in a cookie which expires.

[ghost]

Nice to learn about async-cookies-api, never heard of it before.

BTW, I do believe nobody should explicitly encrypt their content manually in indexedDB, neither cookie, json, jpeg, html or any text content serve over HTTPS.

But if anyone, or any existing browser, believe ending an HTTPS session should void the cached resources of those URLs. The dividing/generated content from these URL should be voided too.

As far as I know, most browsers (correct me if it is IE only or old decade) will delete those cached HTTPS resources, or just ignore them on next relaunch.
Many internet bankings still suggest you to close the browser after logout to avoid history / cache leak.

On second thought, we need a different API to teach browser what to flush on session end, and another API to fire the event.

[inexorabletash]

... and https://w3c.github.io/webappsec-clear-site-data/ might be helpful to learn about too.

[jimmywarting]

Will just throw in my two cents here: What about using the Crypto api to generate a key?

[Zazck]

@inexorabletash I'm facing a problem on encryption. I'm planning to storage chat history and user images in IndexedDB, the point is. a browser may not used by only one user, It may have multiple user using same browser at once. If I encrypt those messages one by one, it seems very stupid. I wonder if a method could encrypt the whole database and prevent other user scoping those data by devtools. well...I think I just have to make a client with postgresql in it.

[nolanlawson]

This topic came up internally as well. Lots of enterprises want on-device storage encryption (e.g. see SQLCipher which is popular for SQLite in native apps). One suggestion was to extend the manifest with something like:

{
  "encrypted": true
}

Ideally though this would encrypt all forms of origin storage - LocalStorage, cookies, IDB, caches, etc. There'd also need to be an API surface so that developers can feature-detect and fall back to the WebCrypto API in cases where the built-in encryption is unsupported.

[NullVoxPopuli]

is there anything holding this up? does it need a champion? or something else?

[iskandergaba]

Any news on this, champs?

[Sora2455]

You can hack this together with the Crypto API if you have to.

JSON.Stringify (IE8+) -> TextEncoder (polyfillable) -> crypto.subtle.encrypt (Edge and up, IE11 if you're willing to handle a non-promise result) -> IDBObjectStore.add() (IE10+) saves any JSON data to disk encrypted.

IDBObjectStore.get() -> crypto.subtle.decrypt -> TextDecoder -> JSON.Parse gets it back out again.

Really, the hard part is key management, as it usually is with these things. Personally, I include it in the HTML of the page servers-side, and then retrieve it and remove it from the HTML client-side before any other code has a chance to run. If you make sure your key is held in a closure, and that you Object.freeze the APIs in question, you should be safe.

[ghost]

That's exactly the reason why it is better if browser API support. Key management. Today browsers already do password management, credit card management, payment API management, and even keychain/finger print. A piece of API or data that only accessible from the trusted code from trusted origin.

…

On Thu, Jul 25, 2019, 19:44 Sora2455 ***@***.***> wrote: You can hack this together with the Crypto API if you have to. JSON.Stringify (IE8+) -> TextEncoder (polyfillable) -> crypto.subtle.encrypt (Edge and up, IE11 if you're willing to handle a non-promise result) -> IDBObjectStore.add() (IE10+) saves any JSON data to disk encrypted. IDBObjectStore.get() -> crypto.subtle.decrypt -> TextDecoder -> JSON.Parse gets it back out again. Really, the hard part is key management, as it usually is with these things. Personally, I include it in the HTML of the page servers-side, retrieve it and remove it from the HTML client-side before any other code has a chance to run. If you make sure your key is held in a closure, and that you Object.freeze the APIs in question, you should be safe. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#191?email_source=notifications&email_token=AAN5UK3DJ7MEGD4H5L4AXATQBGG3HA5CNFSM4DIKJ3K2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2ZHITY#issuecomment-515011663>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN5UK54ZJDU2IYQLHHKENDQBGG3HANCNFSM4DIKJ3KQ> .

[inexorabletash]

TPAC 2019 Web Apps Indexed DB triage notes:

We think doing this as part of Storage Buckets makes the most sense.

[everlose]

I'm facing a problem on encryption. I'm planning to storage chat history and user images in IndexedDB, the point is. a browser may not used by only one user, It may have multiple user using same browser at once. If I encrypt those messages one by one, it seems very stupid. I wonder if a method could encrypt the whole database and prevent other user scoping those data by devtools. well...I think I just have to make a client with postgresql in it.

I'm facing the problem too，so，Did you end up not using indexdb？