Privatebin: Improve security with OTP / HMAC / 2FA

[ZerooCool]

Improve security with OTP / HMAC / 2FA

-> Threat : #177 #345

• 2FA : Learn more.

• OTP : #28 #188

• HMAC : #174

• With Password / Challenge/Response : #245

• Give a false response :
  Another proposal that I have just received, concerning security, would be to give a false message to an identity that does not match. We would then think more of a password failure.

Question :

Finally, I have not yet found information on the rest of the problem: Is it possible that a third-party service downloads the content of a message, even if it is marked as to be burned, and that, despite everything , it remains available to the recipient?

Is this problem still current in the current stable version of PrivateBin?

Note : https://privatebin.info/reports/zerobin-audit.html

[elrido]

Keep in mind that PrivateBin doesn't have a user model and therefore can't (and should not) be able to offer any user authentication. Hence 2FA makes no sense, as we don't even offer single FA.

Yes, anyone with the link can open that burn-after-reading paste. The server doesn't know (nor does it want to know, by design) if whoever requests the paste is the intended recipient or a third party. The look the same to the server.

What we did implement is the switch to API-only for retrieving pastes. This avoids that sending the link through chat systems that check the website for malware trigger the deletion. An API call can be implemented via curl, but it's easier to use one of the CLI clients that are designed for this. The first read access to the API for a burn-after-reading paste will delete it.

We had attempted to implement an HMAC based challenge response API, but abandoned it when it became clear that the approach in question would weaken the zero-knowledge of the server on the pastes contents.

[ZerooCool]

Ok I try to follow a little, from afar, on these mechanisms.
Can we then consider that we will not be able to download the message (intercept the message) to read it afterwards, once the real address has been recovered, see, the password recovered?

This is the point that interests me because, I understand that it was possible to copy the encrypted message along the way, without destroying it, and deliver it to the recipient, then read the message intercepted since the full address will have been identified, allowing decryption (unless a password is used) (but if a password is then used, brute force attempts are valid, if a person has recovered the message at middle, since he can at leisure attempt bruteforce, even if it takes time.)

Can you see to re-explain this to me, to date, or in short we on this type of possibilities and risks.

[elrido]

When using HTTP, the message can be trivially captured and stored or manipulated in during transmission. With HTTPS this is more difficult, but still possible for anyone controlling a CA certificate that made it into the certificate trust store of your client (say, the Active Directories CA on your domain joined, corporate Windows client).

• PrivateBin offers no (perfect) forward secrecy - if the key leaks, any intercepted messages can be decrypted.
• We do use the message authentication mechanism of AES GCM - which means simple, in-flight manipulations of the transmitted message without knowledge of the key will cause it to fail to decrypt. The attacker would need to know the key to decrypt, then manipulate and re-encrypt the message on the fly. An attacker sophisticated enough to do man-on-the-middle attack on HTTPS has the CPU power to do this fast enough for the user not to notice. There are commercial products designed for this that are in widespread use.

If this is a concern for the type of messages you intend to share, please use a tool designed to provide end-to-end encryption. The focus of privatebin is to provide a pastebin...
https://github.com/PrivateBin/PrivateBin/blob/e35a26c9166d85b615a9c696c028a5cde95481c3/README.md#L6
So this tool is chiefly designed to protect the server from getting to know the contents of the paste, but not third parites. To the user this ideally functions just as seamlessly as a non-encrypting pastebin service, with the added benefit that the server can't redact the paste. But the server can still censor the paste as a whole and delete it.

I hope I have understood your questions correctly and could answer them all.

[ZerooCool]

Rather clear overall.

Is that enough to reassure an average user, I don't know.
Some people generally said to me: "This is shit, you are the police, and, we cannot trust your tool."

This is sometimes true, moreover, we cannot trust people who cheat, manipulate data, and participate in the harassment of citizens, therefore, we can understand their position.

Understanding the security mechanism is a good thing to reassure people, but then you realize that nothing is perfect and that there are often flaws.

I would not know to date, make a man the middle, and, I do not know the most suitable and free tool, to do that. Perhaps commercial, specialized tools, for certain administrations, are more suitable, and, therefore, I would not turn to this kind of solutions.

I'm still more concerned about the ability to get information through the browser, and how to tell people about it whether or not privatebin is secure.
I suppose it would take a virus, malware, to compromise privatebin, it would have to be already installed and running, see, should it be installed once a target has been identified? That still puts a few conditional factors in place, so, I guess it's not so obvious, anyway, for the average person, who is not a computer scientist, it seems to be a real challenge.

Now, I would like to manage to approach this aspect, on a more professional side, even see, succeeding in making a hack, to capture a key, but, that would require a lot of work, to know the API, to know the mechanisms, the tools, perform tests ...

[elrido]

It really depends on the angle of attack you are going for: Assuming the attacker can either manipulate the HTML in flight or because they gained access to the server, then you can emulate that simply by editing the template, adding yet another JS file to load from the same server (so that the CSP header doesn't prevent it to be loaded) and in that JavaScript files you could add a keylogger, or more realistically, some hooks to the password field ($('#password')) and for changes to the pastelink-div ($('#pastelink')) and when found, extract paste link plus password and forward it to your evil c'n'c server and voilà, you collected the encrypted message and key.

Therefore, to the user questioning the security of the service, simply ask them if they trust you. If not, they better run their own server. The security of anything written in javascript lies primarily in the trust on the webserver serving it and those operating it. This is one of the reasons why we still use applications outside of our browsers, after all - as opposed to the view that the browser should ultimately become the universal client used for everything and the only application ever needed.

[ZerooCool]

Yes that's why I asked if there was a way to make sure in one click, that the code is original, and, you told me about SRI actually, that we can check, but, if we has access to the server, then we can modify the SRI.
Nevertheless, a one-click control mechanism could be interesting, if that is possible anyway?
For example, compare the existing SRI with those of the official project.
But, if I understand, this would not necessarily prevent the inclusion of new unofficial scripts, which could veroler the mechanism.
So you have to be able to trust the server, which is not necessarily an easy task.

[rugk]

I think there is nothing more to be said there.
Our threat model is well documented and what we can offer and cannot offer is also stated there.

For possibilities to improve things, you've linked them already and they are tracked in these issues there. Also see #627 e.g. for the idea to have a browser add-on to verify the SRI hashes/JS. (Unfortunately that idea never went over being a proof of concept.)

Note : https://privatebin.info/reports/zerobin-audit.html

BTW this had been fully addressed in PrivateBin v1.0 already.

So you have to be able to trust the server

Yes, you have. Period.
See also our FAQ, e.g. here: https://github.com/PrivateBin/PrivateBin/wiki/FAQ#but-javascript-encryption-is-not-secure

As it seems this question has been answered and I thus close this issue. If anyone has further questions on that topic, feel free to comment here, again.