'How to correctly store user secrets in a frontend Application?

I am building a Web Application where the user's data is end-to-end-encrypted.

The web client obviously needs a secret that nobody else knows for end-to-end-encryption to work.

I have planned to have the user choose a password and then derive an encryption key from it.

Currently, the user has to enter his password again, once he reloads my single-page-app, as the secret is not stored on disk, because storing it in localstorage is probably bad from a security standpoint.

In a native app I'd use something like the keychain to securely store such secrets. What would I use on the web?

I know the Credential Management API exists, this doesn't work for me because Safari on iOS doesn't support it.

What are the best practices to store user secrets on device from a Web Application? (Preferably without user interaction when retrieving the stored password)



Solution 1:[1]

If you want to enable end to end encryption within the browser, it is possible to do via javascript (Not Completely though, due to the below reasons).

Proton mail claims that it has end to end encryption enabled in its service and is possible via a Javascript file that is shared by the server to the client(end-user).

However, a researcher challenged that it's not completely end to end encrypted. He explains that if the server is compromised, and a malicious javascript is sent by the server to the client, the server can read all its private key. You can read more about the blog and research paper and discussion here:

This blog shows how it's possible to create a key using javascript which cannot be accessed by the server, but the challenge here is that you share the url to the end user via a different channel.

Possible Solution:

We can let the client generate a private key locally and store the public key associated with it, on the server. However to decrypt the message, it will require the private key again. For this we can make use of browser extensions that will store the private keys, and decode the messages on the fly (client Side).

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1