Encryption and decryption in the browser on the client's side – is it safe?

Question

There is a possibility to download the file with one’s PII from the dedicated web server. The file might be decrypted by filling the two factors. These two factors are delivered via email and SMS. The sum of these factors is the key from which is generated the hash by, let’s say, bcrypt. This hash is the main password to decrypt the PII from this file. It is transparent for the user. The user only needs to provide these two factors. All processes: scaling two factors, making hash, decryption; are executed in the browser (java) on the client's computer, on the client's side.

In my opinion, it is not good practice and not safe. The process of decryption is on the client's computer. Also, the algorithm is delivered on the client computer. Because it is written in Java so it is possible to find out about the function that is used to decrypt the file. The attacker can steal the file and the knowledge and try to gain access to the file. The main security of confidentiality is based on a strong algorithm like bcrypt.

What is your opinion about this case? Or maybe I am crazy about it and wrong and this is a good and safe practice.

Answer 1

Let's put some of the specific technical implementation details aside and focus on what you have asked or assumed:

• is decryption on the client-side safe?
• is finding out what encryption has been used a problem?
• is a strong hash as a key strong security?

Decrypting client-side

There is nothing wrong with having all the decryption client-side, and for very secure implementations, it's actually preferable. If it is all client-side, then the transmitting and storage is all inherently encrypted. "But an attacker could steal it from the client!" Yes, but they could do that anyway. PII is all over a client machine. If an attacker has access to the client device, they have everything anyway.

Knowing the encryption algorithm

There is a concept in cryptography called "Kerckhoffs's principle", which proposes that all encryption should aim to be safe even if an attacker knows exactly what encryption method was used. The only secret thing should be the key. All approved encryption algorithms meet Kerckhoffs's, so no, it's not a problem if an attacker knows how the file was encrypted.

Hash as key

The problem with your key generation idea is that the different factors and how you use them to create a hash which becomes the key doesn't matter. The final string is the password to the file. If the file needs to be opened again, the string can be saved, stored, and reused. So all your work to "protect" the key is defeated. You just created an awfully inconvenient random string generator.

And if you purposely prevent the user from doing this, you cannot prevent an attacker from creating their own version of your Java app and simply cutting out all your controls. So all you will end up doing is making it very difficult for users.

What to do

You could simplify your entire process by simply using standard Java encryption libraries and protect the encryption key with a user password. This is what online password managers do, and they protect data far more sensitive than PII.