[ABD] [DEV] Encrypted PMs

[dingus33]

yup, only way users can protect themselves from admin is to use GPG or something in PMs and handle crypto and keysharing outside of the forum.

[dingus33]

Okay. Something about that seems "impossible", since having access to the DB and the file system gives the site owner(s) access to everything the extension has access to, and the extension is able to decrypt them. But perhaps there is still a piece that is not described or not being taken into account.

if i understand correctly, the user's pw would need to be entered both at the time of key generation and also every time a PM is decrypted.

Which is how we landed on the assertion "someone viewing only the database information" is who is now locked out of viewing the stored private messages, as opposed to "the site owner(s) were prevented from seeing your message." The site owner(s) have all the same abilities the extension itself has, and is not something the extension can unilaterally protect against.

yes, i think that the extension as-described would only mitigate risks from db and fs theft (of backups perhaps). it would not mitigate risks from the server getting pwned and a bad actor having access to the live site (and certainly would not protect against a malicious admin). they could capture passwords that way easily.

[canonknipser]

yup, only way users can protect themselves from admin is to use GPG or something in PMs and handle crypto and keysharing outside of the forum.

Much easier:
Just share mail addy or some messenger contact data and communicate outside the board instead of only sharing krypto information outside

[Toxyy]

Just share mail addy or some messenger contact data and communicate outside the board instead of only sharing krypto information outside

Again I must advocate for a use case for this extension or such things.

There are forums out there right now that rely on PGP/GPG communication on site, despite users having to decrypt it themselves. Saying that it is easier to do X is a little moot.

And I was going to respond saying that GPG is a better alternative than relying on a password/master password (master password really kind of defeats the purpose of this, doesn't it?). Your public key could be stored on your profile and you could "auto encrypt" messages send to others who have their GPG keys on their respective profiles. That's about the best you could get for encrypting messages, unless there's some new development I'm unaware of.

I do appreciate the extension. I'm not sure why there are a few here who ignore the potential of it. That said, Senky, having them encrypted via a password or what not only makes it slightly harder for admins to read PMs not impossible. There are established ways of encrypted communication which avoid MITM attacks entirely, assuming no super computer tries to crack it, and you're using at least 2048 bit. Again I'm assuming there's no replacement for PGP/GPG that I know of anyways, but that is the only end-all for this that I can see.

But it looks like everyone is missing the point here. You as admin can offer your users a real secured channel. Heck, even CIA can't break that one. It is not about users, it is about admins to behave responsible and value user privacy.

As it's built now its kind of trying to recreate the conditions for pgp and is not secure, as others have pointed out. Anyone with malicious intent and admin level access, you can assume, can also change the files to echo out the user password before it's put into the db and hashed itself, must not forget. You can't rely on user passwords.

EDIT: I realized I talked myself into a little bit of a hole on this one. I realized that, if someone did indeed have file level access, nothing would prevent them from altering this extension to output messages before they are encrypted with the public key, no? Same methodology as echoing the password.

Hmm... feels like I'm forgetting something.

[fagbutlil]

I would honestly suggest for this to be added to the core of phpbb

Would not take 3 minutes to remove it.

[martti]

Providing a false feeling of security is worse than insecurity.

[Senky]

Okay. Something about that seems "impossible", since having access to the DB and the file system gives the site owner(s) access to everything the extension has access to, and the extension is able to decrypt them. But perhaps there is still a piece that is not described or not being taken into account.

Technically you are right, but there are cases when an attacker can access files but cannot modify them. In that case he is unable to pull password out of the request.

Presuming the private key for the user needs to be decrypted and then re-encrypted during a password change (so that the key is encrypted with the new user password), adding some UI to the "password reset" actions available to both users and administrators could be important. Meaning additional warning text for admin password reset, and for user forgotten password reset, that declares what the ramifications will be for changing the user's password without knowing their existing password. Bonus points for the message to be repeated or more insistent if the user actually has sent one or more encrypted messages, and data loss would occur.

That is an excellent idea!

Although the benefit of being "entirely transparent" is clear, the users trust in the site owner & the extension might be improved by being able to see "this message is actually encrypted." Meaning, although they might eventually leave the checkbox checked to "always decrypt by default", giving the reader a checkbox to let them see what the message looks like without applying decryption could improve their confidence that "something is being protected" now.

The checkbox will be present all the time. UCP option would just check it by default.

Anyone with malicious intent and admin level access, you can assume, can also change the files to echo out the user password before it's put into the db and hashed itself, must not forget. You can't rely on user passwords.

That leads me to an idea of hashing password client-side. Opponents might say that again, someone with access to files can output a small JS code that will track user keyboard and send it over to the server. But such an extreme case can apply to any end-to-end encrypting messenger: Is protonmail secure? Anyone who can access their filesystem can obtain your password and decrypt the mails. Do we consider protonmail insecure now? Any browser extension can potentially read your password as you type it. Is any browser-based messenger insecure now?

Don't get me wrong. I will happily implement any security measurements which are possible.

[canonknipser]

What about reporting a encrypted PM? Do the moderators handling the report need the keys as well?

[Senky]

What about reporting a encrypted PM? Do the moderators handling the report need the keys as well?

You won't be able to report the PM directly. You can, however, forward it to the moderator in decrypted form.

[canonknipser]

This is a step back, I think.
Forwarding means you either need to know in advance which moderator handles your case or you need a group pm permission (and a lot of people don't know how to send messages to groups)
Other disadvantage is during forwarding a message you can manipulate it, with reporting you can't.
And reporting is a three-click-action ...

[Mick]

I think this is a great idea but it would be better in the core and UCP selectable. In fact it should be on by default IMHO.

[Senky]

This is a step back, I think.

I understand your points, it really is much simpler with using reporting button. But in order for messages to be truly encrypted, I can't allow moderators to look at them. If every moderator owned a key for every message, it beats the whole purpose.

[david63]

I can't allow moderators to look at them. If every moderator owned a key for every message, it beats the whole purpose.

But moderators would only be able to read them if they were reported to them. Reporting of messages MUST remain as a feature.

[Ger]

I understand your points, it really is much simpler with using reporting button. But in order for messages to be truly encrypted, I can't allow moderators to look at them. If every moderator owned a key for every message, it beats the whole purpose.

Why not simply offer the option to decrypt the PM and report it at that point? You would need a clear info message stating the PM won't be encrypted anymore once reported though.

Anyway, I agree with Mick though:

I think this is a great idea but it would be better in the core and UCP selectable. In fact it should be on by default IMHO.

[fagbutlil]

Why are they called PRIVATE messages when phpbb knows there not private at all ? thats another balls up from phpbb lets call them private messages knowing there not private and can be read straight out of the database they should be renamed to just Messages.