4 ms·

Yes you are right, nothing. However that is a different and much more difficult kind of attack than the common one where an attacker retrieves all the files st

Yes you are right, nothing. However that is a different and much more difficult kind of attack than the common one where an attacker retrieves all the files stored on the server and goes away. Also I'm really not sure if such a determined attacker could be stopped somehow... Any suggestions?

c22 5y ago
Whether or not an active attack is much more difficult than a passive one depends on the specific security profile of the entire service. Often a passive data-exfiltrating attack will become possible due to an innocent mis-configuration on the server, but mis-configuration can open the door to active attacks as well. There is no guarantee that any mistake in configuration will only allow passive attacks or that an attacker will choose to just "go away" after retrieving all of your files. With this system, specifically, active attacks will be quite rewarding to any potential attacker because secrets are saved indefinitely and every user-key they steal will allow the recovery of multiple secrets. Since the rewards are high you should expect the chances of active attack to be heightened. In order to mitigate against this you need the enduser to be able to verify the proper functioning of the encryption/decryption apparatus. Usually this is accomplished with separate binaries, checksums, reproducible builds, and etc. Of course any solution will be vulnerable during updates of the encryption/decryption endpoints, often an out-of-band channel is used to transfer the update or the verification checksum. These challenges are particularly fraught when attempting to implement a secure system using in-browser javascript. Not only is the entire encryption/decryption algorithm redistributed frequently, regardless of whether or not it has changed, but the tooling around authentication and validation of browser-resident javascript is currently very weak. In addition to compromise of the server, the system is still vulnerable to local attacks as well as a whole host of in-transit attacks that more static e2e systems don't have to worry about (e.g. someone forgets to enable https, or happens to connect through a suss proxy). Perhaps some sort of javascript pinning could help to alleviate some of the threat-surface, but to my knowledge no major browsers support anything like that.
- spapas82 5y ago
  Thank you for this great explanation! I understand that the prolem is inherent in in web-ased security systems and not much can be done. However, let's suppose that I packed the client functionality to an electron app (i.e executable with some signature) so the .js files doing the encryption/decryption would not be downloaded from the server each time but they would reside inside the electron app. Would that be better from a security standpoint against the attacks you mention or I'm missing something?
  - c22 5y ago
    Yes, this would be better. You would just have to be careful about how you distribute the app.
    - spapas82 5y ago
      Excellent thank you so much!

c22 5y ago

Whether or not an active attack is much more difficult than a passive one depends on the specific security profile of the entire service. Often a passive data-exfiltrating attack will become possible due to an innocent mis-configuration on the server, but mis-configuration can open the door to active attacks as well. There is no guarantee that any mistake in configuration will only allow passive attacks or that an attacker will choose to just "go away" after retrieving all of your files. With this system, specifically, active attacks will be quite rewarding to any potential attacker because secrets are saved indefinitely and every user-key they steal will allow the recovery of multiple secrets. Since the rewards are high you should expect the chances of active attack to be heightened. In order to mitigate against this you need the enduser to be able to verify the proper functioning of the encryption/decryption apparatus. Usually this is accomplished with separate binaries, checksums, reproducible builds, and etc. Of course any solution will be vulnerable during updates of the encryption/decryption endpoints, often an out-of-band channel is used to transfer the update or the verification checksum. These challenges are particularly fraught when attempting to implement a secure system using in-browser javascript. Not only is the entire encryption/decryption algorithm redistributed frequently, regardless of whether or not it has changed, but the tooling around authentication and validation of browser-resident javascript is currently very weak. In addition to compromise of the server, the system is still vulnerable to local attacks as well as a whole host of in-transit attacks that more static e2e systems don't have to worry about (e.g. someone forgets to enable https, or happens to connect through a suss proxy). Perhaps some sort of javascript pinning could help to alleviate some of the threat-surface, but to my knowledge no major browsers support anything like that.

spapas82 5y ago
Thank you for this great explanation! I understand that the prolem is inherent in in web-ased security systems and not much can be done. However, let's suppose that I packed the client functionality to an electron app (i.e executable with some signature) so the .js files doing the encryption/decryption would not be downloaded from the server each time but they would reside inside the electron app. Would that be better from a security standpoint against the attacks you mention or I'm missing something?
- c22 5y ago
  Yes, this would be better. You would just have to be careful about how you distribute the app.
  - spapas82 5y ago
    Excellent thank you so much!