Open DaveMBush opened 1 year ago
Why is it not enough to secure the browser managed database files using user account permissions?
What is different between them viewing it in an app vs viewing it through devtools or by loading the indexeddb files in some third party tool?
Most importantly, because my security team won't let me store anything into indexDb unless it is not sensitive or it is encrypted with a security key unique to each user who logs in.
Say user A logs in and views their data which is stored into indexDb and it has sensitive data. Medical records, legal documents, or tax information.
User B logs in to view their data, and should not be able to see user A's data. But because it isn't encrypted and they are on the same domain, they can see everything that was stored for user A.
In an ideal implementation, User A would have their own data storage or sets of storage) and user B would have their own storage. Each would be encrypted with unique keys so neither can see the other's information.
Yeah, this is a common request.
We've resisted because encrypting the data within a user account is not a way to prevent two users sharing a login from seeing each others' data. User A could simply install a browser extension that snarfs all data out of the browser when user B logs in. This can be done even if no data is stored in IDB. And encrypting the data in IDB doesn't help.
There is no secure way to allow two users to use the same login. The purpose of user accounts on computers is to keep user data separate from each other. There is not a way to achieve that other than using accounts.
That all said, if you do want to encrypt data stored in Replicache you can do so. You can communicate a key to the client at login time and encrypt all your values before you store them, and decrypt on read.
We don't provide a facility for it because we don't want to encourage a false sense of security, but it's easy enough to do in user code if you want.
Also, User A's data will almost certainly be unencrypted in the HTTP cache on the browser when User B logs in -- unless you are being very careful to prevent that.
Another thing you could do to make your security team happier is to use a checkbox when you log in saying something like "This is a shared computer" which when checked does not store anything locally. You can replace the persistent storage layer in Replicache with an in memory one using the experimentalKVStore API.
The org I work for, and many I've worked with in the past, would need to have the data encrypted in order to store it anywhere someone could view it.