Misleading security claim: User data is protected even in case of server breach or seizure

[northox]

Hello,

The list of benefits of the main page claims:

User data is protected even in case of server breach or seizure.

However, we can read a conflicting statement in the drawbacks section of the same page, i.e.:

Users still have to trust the server regarding the respect of their privacy. ZeroBin won't protect the users against malicious servers.

Also, the FAQ clearly state that ZeroBin cannot protect the user from a malicious server.

Since a breached server can clearly be a malicious server, I strongly recommend removing this misleading claim and adding something corresponding to the drawbacks section, e.g., breach or seizure of the server can result in access to user's data.

Technically, we're talking about a malicious user or police agency having access to the server and modifying the code to retrieve the encryption key. At that moment, whenever you access your encrypted information, some javascript (or any other client side code) could send back your key to the server, i.e. the portion after the # character.

I believe a potential solution might be provided by the new Web Crypto API but I'm really not sure. Maybe a browser plugin could to the trick but again, I'm really not sure. It's not my area of research. I'm simply giving hint.

regards,

For reference: http://sebsauvage.net/wiki/doku.php?id=php:zerobin_discussion&#comment_1dbe75ab3779b5dbd09f9f88210f89c9

[rugk]

As explained in https://github.com/elrido/ZeroBin/issues/8 you're right that this statement is wrong:

User data is protected even in case of server breach or seizure.

However you can extend it to make it correct:

Previously encrypted user data is protected even in case of server breach or seizure if the previous operator did not modify the source code maliciously and no user accesses the data with the correct encryption key after the breach.

To break this down into 3 points: User data is protected after server breach if...

• it was created before the server breach (because all further requests and encryption processes can be modified by an attacker)
• the previous hoster, so the server operator who owned the server before the breach, did not do anything malicious
• no user requests the encrypted content and provides the correct encryption key, because if they do so the attacker could just grab the encryption key with a bit JS and decrypt the data.
  If you have your server back under your own control this is obviously no issue anymore.

Additionally we also have to assume that there are no weaknesses in the encryption the attacker could use to decrypt the data. And if you should experience a data breach you should shut down the server as fast as possible so that the first and third cases do not happen. If you do so you only have one thing the user has to trust: Yourself - the server operator. And here we have the first quote again. :smiley: