Client side encryption of user data with user password

Question

I've narrowed down on a scheme that would allow my application to encrypt user data client side and transmit that data to the server, with no chance of our server ever being able to decrypt the data.

I want to ensure there are no obvious flaws in this scheme.

Method

Note: every step below happens on the client side.

Precursor:

1. Upon login/registration, generate global key gk = SHA256(user_password) and store gk in a cookie localStorage. (The reason for this is to not store the user's password plainly.)

Encrypting:

1. For every file, generate a random key fk.
2. Encrypt file with fk.
3. Encrypt fk with gk to get fk'.
4. Transmit encrypted file and fk' to server for storage.

Decrypting:

1. Receive encrypted file and fk' from server.
2. Decrypt fk' using gk to get fk.
3. Decrypt file using fk.

When user changes password:

1. For every file, decrypt fk' using current gk to get fk.
2. Generate new gk using new password.
3. Encrypt fk with new gk to get fk'.
4. Transmit new file fk' to server for storage.

When user forgets password:

1. Out of luck. (Unless?)

What flaws exist in this procedure?

Update

One flaw is that if the user authenticates login with a password, then technically, I can easily compute and store gk on the server, thus compromising the promise of client side encryption.

A solution to this:

1. Generate pw = SHA256(SHA256(user_password)) and send this to the server as the user's password. The server then receives this password, and encrypts it again before storing it.

So as far as the server is concerned, it's just receiving a regular password. But this way, gk cannot be computed server side.

Flaws?

Answer 1

The biggest flaw in this scheme is that it depends on javascript code that will be transmitted to the client by the (a) server.

So, what's to keep the server (or a man in the middle) to send the client modified javascript that circumvents all the security measures? How would the client, or, for that matter, the user ever know? All the code that you write to check fingerprints, checksums, digital signatures etc can likewise be circumvented.

A related problem is other, malicious javascript code running in your Browser that can't be reliably isolated from your security-related javascript code.

This is impossible to fix. In-Browser Javascript is currently not a secure platform and all browser client-side cryptography suffers from this gaping security hole that can't be closed.

Summary of the discussion in the comments regarding the updated question

Calculating pw = sha256(sha256(user_password)) strikes me as a bad idea for several reasons.

1. The first one was already mentioned by AgentMe: Don't use simple hash functions such as sha-whatever to hash passwords. These hash functions were designed to be implemented efficiently in hardware and are much, much too fast; to hash passwords, you want slow hash functions. See AgentMe's answer.
2. With this scheme, pw can be calculated if you know gk (which is just sha256(user_password)). So when someone steals your localstorage, you give him access both to the master encryption key and to the authentication/authorization token he needs to download the encrypted files. It would be better to keep the two secrets independent of each other, so if one is compromised by a third party, it's not enough to calculate the other one and break the confidentiality of the encrypted data.
3. Finally, you're not salting your user_password with this scheme. This means that identical passwords across your whole userbase will yield identical hash values (and there are already large rainbow tables for unsalted sha-hashes out there containing the few million most common passwords).

You suggest an alternative, e.g. gk=sha256(user_password) and pw=sha128(user_password). While this solves point 2, it doesn't address 1 und 3. Also I wouldn't recommend it because I could imagine that this needlessly provides additional information to an attacker (the same password hashed to two different hash values), even though I don't know how to exploit it.

I suggested using gk=hmac(user_password, n) and pw=hmac(user_password, m), where m and n are known, but different for each user. How you arrive at m and n is irrelevant, as long as they're random and sufficiently large to make them unique across your user base with a high probability. You could create them on the client and submit them for storage at the server, indexed by the username so they can be retrieved on other clients. Or you can have the server generate them when the user first creates an account. The values don't need to be kept secure; they're worthless without the user_password. An improvement improvement would be to use gk=hmac(bcrypt(user_password), n) and pw=hmac(bcrypt(user_password), m) to make brute force attacks harder.

Now, I'm not convinced that this suggestion is a good idea, since hmac is designed for message authentication, not for creating authentication tokens or encryption keys, so I'd take that suggestion with a grain of salt. But it seems to solve all three points I raise, so it seems like a better solution than chaining the same hash function or using two different hash functions on the password.

Answer 2

1. gk needs to be stored in localStorage/IndexedDB and not a cookie, because cookies get sent to the server!
2. You should use a stronger password hashing / key derivation algorithm than SHA256 which is more resistant to brute-force.
3. How does the user authenticate to the server? You probably don't want to let just any user request or update the encrypted fk' files for any other user. You'll want users to authenticate in a way besides sending their plaintext password. You could have them send the gk value put through the key derivation function a second time.
4. See https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/. You (or someone coercing you, or someone who has hacked you) can get user data by changing the javascript your server gives so that it sends the users' gk values back to the server or otherwise leaks them. This could be mitigated with good use of service workers that have openly-reviewed code but I'm not sure anyone has done that satisfactorily yet.