4 ms·

The FAQ describes how the data center is using super-sophisticated security. Why is this necessary if the data is encrypted at the client? (perhaps I'm missing

The FAQ describes how the data center is using super-sophisticated security. Why is this necessary if the data is encrypted at the client? (perhaps I'm missing something about the threat model).

sjs382 11y ago
It isn't important, but it's still a detail that some people who are security-conscious might care about.
- locacorten 11y ago
  I'm sorry but I beg to differ. Encryption is a very powerful tool -- the whole point of doing encryption at the client is that we don't care about data center security any more. As long as the data isn't lost, my data remains confidential. NSA, KGB, the Chinese hackers can't read my data. Period. If you start telling me that I'm paying for security measures that have no effect on your service security guarantees, I think you're selling snake-oil. At this point, I'm very reluctant to trust my data to your service.
  - sjs382 11y ago
    You aren't paying for it. It's provided my my server provider, DigitalOcean.
    - locacorten 11y ago
      May I suggest you make this clear in the FAQ? In its current format, the FAQ makes it a big deal out of it without explaining that it's an additional security measure and that client-side encryption alone is sufficient to protect the data.
  - MichaelGG 11y ago
    The client side crypto is only as strong as the server side security. If, as an example, I get DigitalOcean to reset the password on the VM (or any other way to access the web servers) then I can simply add another line to the JS to post the plaintext data to a server of my choice. Game over. You should use PF if you trust them not to be compromised (hacked or be malicious) and not to backdoor the software. It shouldn't hinge on the client side crypto.
bwblabs 11y ago
I cannot try anything before entering my CC number (and paying, no free month or anything), nor finding any detailed information about the setup (apart from 'public/private key client side JS'). But the site/server/data center security probably does matter if the JS is hosted at their site / servers. Edit: See link below: https://privateforms.net/embed/rNKlzL https://privateforms.net/embed/rNKlzL So you get jquery, moment, bootstrap + datatimepicker, kbpgp and a few lines of glue to use kbpgp to send and XMLHttpRequest, basically: kbpgp.KeyManager.import_from_armored_pgp({ armored: '-----BEGIN PGP PUBLIC KEY BLOCK-----\n' + /* key */ '-----END PGP PUBLIC KEY BLOCK-----'}, function(err, keyManager) { kbpgp.box({msg: '**form=data**', encrypt_for: keyManager}, function(err, encryptedString, encryptedBuffer) { //send result; } ); });
- locacorten 11y ago
  I like your answer because you're describing a new threat model: an adversary tries to subvert the encryption process. Their service does not protect against such a threat. Securing the data center is the least of your worries for such an attacker. I'd detail additional attacks that all subvert the encryption process: 1. Compromise the site's private SSL certificate. This allows the possibility of MITM attacks. There is some evidence that NSA is already mounting such attacks on the Internet. 2. Malware on the client-side. A compromised browser, or a compromised OS. 3. The US government mandating that NSA installs hidden firmware on all data center servers. I argue that strong semantics are extremely important when building secure services. I thought their service offers one such semantic: client-side form data encryption. They do not offer JS code integrity or any guarantees about the client-side encryption not being subverted. By telling people about datacenter security and then calling it a "a detail that some people who are security-conscious might care about" or "data center security probably does matter", you continue to raise the fog of confusion in people's minds. Instead, the FAQ could educate the users and separate client-side encryption (which is what the service offers) from client-side code integrity (which the service does not offer).
  - MichaelGG 11y ago

The FAQ describes how the data center is using super-sophisticated security. Why is this necessary if the data is encrypted at the client? (perhaps I'm missing something about the threat model).

sjs382 11y ago

It isn't important, but it's still a detail that some people who are security-conscious might care about.

locacorten 11y ago
I'm sorry but I beg to differ. Encryption is a very powerful tool -- the whole point of doing encryption at the client is that we don't care about data center security any more. As long as the data isn't lost, my data remains confidential. NSA, KGB, the Chinese hackers can't read my data. Period. If you start telling me that I'm paying for security measures that have no effect on your service security guarantees, I think you're selling snake-oil. At this point, I'm very reluctant to trust my data to your service.
- sjs382 11y ago
  You aren't paying for it. It's provided my my server provider, DigitalOcean.
  - locacorten 11y ago
    May I suggest you make this clear in the FAQ? In its current format, the FAQ makes it a big deal out of it without explaining that it's an additional security measure and that client-side encryption alone is sufficient to protect the data.
- MichaelGG 11y ago
  The client side crypto is only as strong as the server side security. If, as an example, I get DigitalOcean to reset the password on the VM (or any other way to access the web servers) then I can simply add another line to the JS to post the plaintext data to a server of my choice. Game over. You should use PF if you trust them not to be compromised (hacked or be malicious) and not to backdoor the software. It shouldn't hinge on the client side crypto.

bwblabs 11y ago

I cannot try anything before entering my CC number (and paying, no free month or anything), nor finding any detailed information about the setup (apart from 'public/private key client side JS'). But the site/server/data center security probably does matter if the JS is hosted at their site / servers. Edit: See link below: https://privateforms.net/embed/rNKlzL https://privateforms.net/embed/rNKlzL So you get jquery, moment, bootstrap + datatimepicker, kbpgp and a few lines of glue to use kbpgp to send and XMLHttpRequest, basically: kbpgp.KeyManager.import_from_armored_pgp({ armored: '-----BEGIN PGP PUBLIC KEY BLOCK-----\n' + /* key */ '-----END PGP PUBLIC KEY BLOCK-----'}, function(err, keyManager) { kbpgp.box({msg: '**form=data**', encrypt_for: keyManager}, function(err, encryptedString, encryptedBuffer) { //send result; } ); });

locacorten 11y ago
I like your answer because you're describing a new threat model: an adversary tries to subvert the encryption process. Their service does not protect against such a threat. Securing the data center is the least of your worries for such an attacker. I'd detail additional attacks that all subvert the encryption process: 1. Compromise the site's private SSL certificate. This allows the possibility of MITM attacks. There is some evidence that NSA is already mounting such attacks on the Internet. 2. Malware on the client-side. A compromised browser, or a compromised OS. 3. The US government mandating that NSA installs hidden firmware on all data center servers. I argue that strong semantics are extremely important when building secure services. I thought their service offers one such semantic: client-side form data encryption. They do not offer JS code integrity or any guarantees about the client-side encryption not being subverted. By telling people about datacenter security and then calling it a "a detail that some people who are security-conscious might care about" or "data center security probably does matter", you continue to raise the fog of confusion in people's minds. Instead, the FAQ could educate the users and separate client-side encryption (which is what the service offers) from client-side code integrity (which the service does not offer).
- MichaelGG 11y ago