[unknownid]

- Allows transferring encrypted data over an insecure network - Page can be loaded online and decrypted/read offline later - Server cannot track who successfully decrypted the information - If server is compromised by a third party, they cannot retrieve the encryption key from users viewing the document - Among other things

[ComputerGuru]

We use JS encryption heavily in a number of our webapps, so I'm not unfamiliar with its advantages. But relying on JS encryption to provide "security" over unencrypted HTTP is just asking for trouble. It's the "secure on paper, broken in practice" kind of thing that ends up being a huge liability.

[pdx]

Why do you speak of unencrypted HTTP? Who cares? Only AES-256 encrypted data is sent and it's decoded locally. You could publish it on the front page of the New York Times (if anybody reads that anymore) and be secure, because you are publishing encrypted content.

It's really unclear what your point is here.

[iancarroll]

Your unencrypted (or just unauthenticated) HTML page might suddenly start sending the password you enter elsewhere...

[pdx]

Really, how? Because somebody compromised the server? So what? If they did that, all bets are off.

[dpark]

No, because someone MITMs your insecure channel and serves you a malicious page that steals your password and the unencrypted data.

[gjjrfcbugxbhf]

The OPs point is very clear. Js encryption has a lot to do to prove itself before it should be trusted with production secrets.

Furthermore weak encryption is worse than no encryption if it encourages dangerous behavior.

I would add that dropping ssl because you are using something like this would be dangerous behavior.

[paulgb]

Keep in mind that a third party who has compromised the server could change the JavaScript to report password entries back to it.

[pdx]

You are concerned with a compromised server? If I control your server, I can harvest whatever a user types in, even on an HTTPS page.

[jodoherty]

With plain HTTP, it'd be very easy for someone running an open WiFi station or a corrupt ISP to set up a DNS server that points the domain to their own reverse proxy that then can modify the page that the user receives to include some additional JavaScript to forward the user's password or the decrypted page results after the user inputs their password.

This doesn't require compromising any servers, and a lot of laptops will configure their DNS settings based on what the local network's DHCP server sends them.

To the end user, it will appear as though nothing is wrong.

[paulgb]

That's true, but I was responding to a specific claim in the parent post