Hey all,
I’m using the browser sdk in my app after upgrading to V3. Seems encryption keys simply don’t matter when hydrating an existing client. I’ve created a passcode style login system for users which uses a salt in combination with the passcode to regenerate keys for the user. Now, it seems those don’t matter as the db is decrypted regardless of which encryption key is generated. Before I create an example repo, I wanted to drop this in here & get some insight into whether this is something I’m missing or if this is expected behaviour. Based on the docs, I don’t think it is. Appreciate anyone’s insight.
After further investigation, it turns out the browser SDK does not encrypt the db whatsoever.. In fact, it completely ignores encryption keys. Not sure if this is by design, but the docs clearly state that sqlite db is encrypted & dbEncryptionKey is required (it’s not).
Can someone clarify why this is?
hey @chopper, thanks for the post!
sorry about the confusion in the Browser SDK. yes, you are correct. the DB is not encrypted and the dbEncryptionKey option is ignored (at this time).
we’ve updated the docs to reflect this.
the dbEncryptionKey option was required in a previous version of the SDK. the option still exists for consistency with the Node SDK.
the reason DB encryption doesn’t currently work in the browser is due to limitations of the environment. Sqlcipher isn’t supported in WASM yet, and SEE can’t be used on the web because it’s not open source, so putting on web would violate the license. it’s possible to hand roll an encrypted VFS, but there are many other tasks that currently take priority over this.
once encryption on the web is possible, there is the issue of how to securely store the DB password. sure, local storage works fine, but not very secure. we could also prompt for a password every time. something to figure out down the road.
all that being said, the local database should be stored in a secure sandbox and only accessible by the host that created it.