Information Security
cryptography hash javascript client-side
Updated Mon, 05 Sep 2022 03:58:07 GMT

Is any client-sided password just security by obscurity?

Let's say I want to deploy a simple static website (with no backend server) with some protected pages only visible after entering a password.

I could write a hardcoded salted hashed password and encrypt the protected data with it, but the user can still go through the minified JS bundle and find the block that performs the password check which would necessarily have to contain the hashed password or the raw password + hashing algorithm (otherwise how could it check for password correctness or decrypt the content?). I could improve this by performing the password checking in WebAssembly, but with some time and knowledge that could also be decompiled and cracked.

It seems to me that fundamentally in any case where the password checking or protected content exists on the client's machine, it is impossible to have any real security that isn't just security by obfuscation. However then I would ask is this also true for any password protected files with open source specifications and readers like .docx / .zip / .pdf? When I google ways to crack those files it seems like most solutions are brute force, indicating it is non-trivial.

I also see packages like StatiCrypt and PageCrypt and am wondering if these are trivial to crack, and if not how do they work?

TLDR - On a website using backend authentication the user cannot access the password checking code nor protected data until providing the correct password. However if the data is on the client (in cases like a static site or a password protected file) the user has full access to the encrypted data as well as the code that checks passwords and decrypts the data, so is that necessarily only security by obsurity?


I think you are conflating two different concepts here:

  1. Password authentication

  2. Decryption

In (1), the user enters a password, and the system checks if the password entered by the user is the 'correct' password required for authentication.

In (2), the user enters a password, then the system attempts to decrypt some cyphertext using a key derived from that password. If the password is incorrect, then the decryption fails, or the decryption results in meaningless output.

Programs that decrypt .docx / .zip / .pdf files are doing (2), not (1). The same applies to StatiCrypt and PageCrypt.

Comments (2)

  • +1 – Thank you that makes sense! So you're saying in the 2nd case the correct password doesn't have to be stored anywhere in the file... And if the user enters the wrong password for a file and gets a popup saying "Wrong password" that wasn't because it checked it against some stored correct password to determine it was wrong, it's because it attempted decryption with that password and failed (Maybe something like this — Jul 18, 2022 at 18:06  
  • +1 – Yes, that's exactly right! — Jul 18, 2022 at 18:12  

External Links

External links referenced by this document: