search

elrido / ZeroBin

This Project has been renamed and moved to
https://github.com/PrivateBin/PrivateBin
Other
85 stars 8 forks source link

Security considerations #8

Closed elrido closed 8 years ago

elrido commented 9 years ago

As @northox explains in #45:

Currently the security of pastes in ZeroBin is based on the trust in the server provider. As long as we have to use a software library provided at runtime from a remote system (currently the sjcl javascript library) this is an issue. And when using a HTTP connection without certification, one can't even be sure that the library is not manipulated during transfer.

If all major browsers would have a built in crypto API, as is planned with the Web Crypto API we should at least implement it as the main encryption facility and keep sjcl only as an (optional, because it is dangerous) fallback.

Additional issues can be found in the audit of ZeroBin provided by Taylor Hornby (Archive-Link). Most points referring to server side issues have been addressed (that's 2.1, 2.3, 2.7, 2.8). The rest is still open for debate or resolution.

elrido commented 9 years ago

Some of @drewbeer commits reminded me that we should start to switch to sha256 hashes were possible (configurable, so that the deletion links in existing installation could still be used).

Then there is @ziirish ZeroBin2 which uses CryptoJS instead of sjcl. The benefit of this library is to be compatible with the output of openssl, allowing for relatively simple shell scripts to paste content into it (no JS dependency on client side). We might include it as an alternative for sjcl and the above mentioned Web Crypto API.

northox commented 9 years ago

You mean when the Web Crypto API is not available (the main crypto facility)?

drewbeer commented 9 years ago

not sure if its going to possible, doing anything on the server side creates a huge lack of trust for the user. while php code can be modified, a user can always watch there java console and make sure nothing fishy is going on.

northox commented 9 years ago

Web Crypto API is not server side. That's the point.

elrido commented 9 years ago

Oh, cool: Apparently there are already browsers supporting it! We should definitely look into it.

rugk commented 8 years ago

FYI the web crypto API does not solve the issue that you have to trust the server. Because also the web crypto API is used by JS on the client site and if you can manipulate the JS you can do anything - even if you just send every key the user presses to the server. So this trust issue can only be resolved with a local browser extension. Examples of this are the Mega.nz browser extension (for Firefox and Chrome) or another browser extension of another service which website is currently down.

But besides of this all it is of course very much recommend to use the WebCrypto API for cryptographic things in JS. Everything else is flawed and is likely to be insecure.

northox commented 8 years ago

Thanks for the clarification. Haven't look into it but thought there would be something to create private keys under user's control, not the websites directly. Deceiving.

rugk commented 8 years ago

Haven't look into it but thought there would be something to create private keys under user's control

Yes, you can e.g. do this with the keygen HTML tag without JS at all. But not only the creation of the key matters, but it also must be stored secvurely (in this case on the user machine, which is done by keygen). However this does not make sense in this use case, because you have to access the private key later on when you want to decrypt the data. More information about the JS crypto issue e.g. here: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

rugk commented 8 years ago

Therefore this statement on the website is completely right:

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

And this is wrong:

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

So is is right that you have pointed this out already in 2013. However under some circumstances the second statement can be true - I've commented in the other issue.

northox commented 8 years ago

Ok gotha, the decrypted info end up in the same context (along with /potentially/ malicious js). I wonder if the w3c could use something similar but actually the opposite of the iframe sandbox attribute; a context that the website cannot control/reach and can access the private key. Anyway, I'm drifting. Thanks for the info.

rugk commented 8 years ago

I wonder if the w3c could use something similar but actually the opposite of the iframe sandbox attribute; a context that the website cannot control/reach and can access the private key. Anyway, I'm drifting.

I assume that's difficult... For now such a context can only be provided by local addons. Mailvelope e.g. is another addon which does this and it has an API, which even allows providers to interact with the addon a bit without revealing the locally decrypted PGP-data.

elrido commented 8 years ago

This issue was superseded by #20.