5 ms·

- Allows transferring encrypted data over an insecure network - Page can be loaded online and decrypted/read offline later - Server cannot track who successfull

- 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

paulgb 9y ago
Keep in mind that a third party who has compromised the server could change the JavaScript to report password entries back to it.
- pdx 9y ago
  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 9y ago
    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 9y ago
    That's true, but I was responding to a specific claim in the parent post
ComputerGuru 9y ago
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 9y ago
  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 9y ago
    Your unencrypted (or just unauthenticated) HTML page might suddenly start sending the password you enter elsewhere...
    - pdx 9y ago
      Really, how? Because somebody compromised the server? So what? If they did that, all bets are off.
      - dpark 9y ago
        No, because someone MITMs your insecure channel and serves you a malicious page that steals your password and the unencrypted data.
  - gjjrfcbugxbhf 9y ago
    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 9y ago

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

pdx 9y ago
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 9y ago
  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 9y ago
  That's true, but I was responding to a specific claim in the parent post

ComputerGuru 9y ago

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 9y ago
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 9y ago
  Your unencrypted (or just unauthenticated) HTML page might suddenly start sending the password you enter elsewhere...
  - pdx 9y ago
    Really, how? Because somebody compromised the server? So what? If they did that, all bets are off.
    - dpark 9y ago
      No, because someone MITMs your insecure channel and serves you a malicious page that steals your password and the unencrypted data.
- gjjrfcbugxbhf 9y ago
  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.