Letting client encrypt his/her data. How to ensure the client doesn't lose his/her private data?

Question

I am designing a web service where the client is allowed to encrypt his own data on client-side software & then send it to our server, so they can be sure their data is private on our side. Then, if client has encrypted values, we transfer some of server functionalities to client-side where the data is known. We are using AES encryption with salts. I have three questions,

1. People are forgetful. If client forgets the encryption key, I believe it's our fault not providing them a workaround. their data will be lost. So is it reasonable that client-side software can remember the password? does this introduce new vulnerabilities? (I am thinking about keeping unencrypted backups client-side, but isn't it the same as keeping the password alone client-side)?
2. When user wants to change the password, his old data should be downloaded to his client-side software, decrypted with old password, and re-encrypted with new password. Is it reasonable? am I missing something in privacy?
3. Should Salts be kept server-side?

Thanks.

Answer 1

Is it safe to store passwords on the client?

Yes, if done correctly. Depending on the client, they might have access to a secure storage offered by the operating system. Using this storage will allow you to store passwords/keys safely.

Does storing passwords on the client introduce vulnerabilities?

Yes. Knowing a password is always safer than writing something down. Malware on the client PC might be able to read it out, but this is turning into the realm of possibilities.

How should changing the password be implemented?

Downloading the data, decrypting it with the old key and re-encrypting it with the new key is not a good idea. It's not wrong, in the sense that it has some privacy impact, but it's not feasible for large data.

Imagine that your client has to deal with a 2 GB large file. First they would need to download 2 GB, then decrypt 2 GB, then encrypt 2 GB, then upload 2 GB again. And that's just for one file.

A much better approach would be to create two keys: A data encryption key (DEK) and a key encryption key (KEK).

The DEK is chosen randomly through a proper cryptographically secure pseudo-random generator. When implemented correctly, the DEK is impossible to crack. You can either choose one DEK per user, or one DEK per file.

The KEK is derived from the user-supplied password through a modern key-derivation function, such as Argon2d.

As their names imply, the DEK is used to encrypt the actual data. The KEK is used to encrypt the key. Given that the key is rather short (in comparison to the data you might encrypt) with 128 or 256 bit, decryption will be very fast.

When the user wants to change their password, all they have to do is decrypt the DEK with the old KEK, create a new KEK and use it to re-encrypt the DEK. The data never needs to be touched.

How to treat salts?

AES does not require salts. You have no benefit of adding salts. Salts are used to counter pre-calculation of hashes of weak passwords.

Please make sure you understand the reason why certain cryptographic measures exist before attempting to implement them yourself. I personally would suggest contacting a company of security consultants and have them review your cryptographic concept. They will be much better equipped to find flaws and nuances in it, as they will have full access to your concept, rather than limited information on a public site.

What if a user really forgets their password and we don't want to store it?

I would display a warning to the user that appears as follows:

Encrypting your data can lead to irreversible data loss if your key is lost!

<Our Company> treats privacy very seriously. For this reason, we do not ever store your key on our servers. This means that if you forget your password, we have no way of recovering your data.

Please ensure that you use a safe passphrase when encrypting your data, which you will not forget. For more information please click here <link that will lead to some password best practices>

Answer 2

I Believe you need and mechanism different then this. Could you please consider following design flow.

1. User provides a password/passphrase
2. Application generates a PGP key with user input (password/phrase)
3. Application will be able to encrypt with public key & will not use/have password/phrase
4. User will be able to decrypt with private key & will use password/phrase

Answers listed below.

• With PGP, do not store their passwords/phrases, this is users responsibility but warm them at the very first beginning.
• PGP will solve this issue, I believe re-encryption will not be a need.
• With PGP you will not need to salt for PGP passphrase. For application access identity yes store this salt at server side and be sure it is unique for every user. If you need detailed explanation about secure hashing let me know.

Possible Q&A is listed below.

• What is password/passphrase updated: nothing will be changed for you
• Will user have to store PGP private key: This is your strategy, if you have a client you can push this certificate to client without human interaction but I believe having the private key will be more safe for user.

PS. You can divide application access identity and password encryption identity, user can have two different passwords.