I basically outlined what I was getting at in my previous post attempting to articulate threat models and messaging models. My last post may have distracted from that.
###TLDR:
The social and technical landscape has changed since this thread stopped in 2014.
I really like the implementations of PGP notifications by Facebook and the aforementioned WP plugin. Discourse adding that capability would be helpful.
I’d also love to be able to use Discourse messaging secured by something like Signal Protocol so I could avoid Facebook Messenger altogether for private conversations with forum users (currently, we end up shifting back and forth).
My aesthetic preference for encrypting everything likely does not represent most users.
Email notifications with no content leakage would certainly be less useful, but it would alleviate some of the concerns. Thank you for pointing that out.
The way I see it this completely solves “Thread Model 3”
Big Data: User email providers (Gmail, Yahoo!, Microsoft, etc.). Transactional email providers (Mandrill, etc.). Attacks on email in transmission or at rest.
I would only be comfortable solving
Directly in the Discourse mobile app (or whatever packaged desktop app).
I work for a consortium of journalists (ICIJ) that investigates on highly sensitive projects. Most known being the Panama Papers and the Paradise Papers.
I’m about to use Discourse to help our network to coordinate and I wonder if anyone ever come out with solution for encrypted private messaging? Our main concern being: if ever the database get leaked, how can we prevent the attackers to read private messages which could reveal sensitive info about our sources.
With our current forum portal, we already setup a “proxy” service in front of our SMTP that uses GPG to automatically encrypt messages for the known keys. If the key for an email has not been provisioned, the email is not sent.
My suggestion would be to have the actual source info referenced as a general codename – all direct source communication should be through a highly secure medium like Signal.
Assume that anything you say on Slack or in Twitter direct messages will one day be public.
Apply that to Discourse as well.
Discourse is trying to be a facilitator for public discussion and doesn’t put a lot of focus on protecting users from the admins.
As a case in point, the re-naming of “private messages” to “personal messages” – the forum admins need to be able to audit PMs for harassment etc without the abusive participant noticing.
Make sure that your journalists know how to go from a codename & document number to the actual document, and that this actually WORKS, so you don’t have people uploading documents to the forum in order to get their work done.
Yes, we already advise them to use Signal, and of course we have many security instructions like the one @riking mentioned. But each investigation involve hundreds of journalists, not all of them are tech savvy and since there is no ways to ensure they follow our recommendations, we must encrypt as many things as possible to lower risks.
The main things to check with regards to “database being leaked”:
anyone who has admin access to your Discourse can download the DB so limit the number of admins, and perhaps only log in as admin when absolutely required, use a “regular” moderator account typically
anyone who can log into your hosting server can directly grab the database, so strictly limit and control who has login credentials to your hosting server.
Keep Discourse and the host up to date. As is the case for any complicated software, sometimes, security vulnerabilities surface that could lead to the database being compromised. Assuming you won’t be the target of sophisticated attacks that specifically target you, quickly installing patches can eliminate most of that risk.
The underlying issue is that you can not trust the server if you want truly secure messaging between members.
This means that the software used to encrypt and decrypt stuff should not be sent from the discourse server.
I second what was said here, you want something like keybase or signal for secure comms, you have to invest in training here. Treat the info you have on Discourse as potentially leaked, there are just too many vectors. People hosting the service, web browser caches on local computers running old exploitable operating systems and so on.
If I was pushed hard to come up with something for journalists discussing highly sensitive info that is Discourse I would
Host the physical server in my house or somewhere I can see it all the time
Use SSL clearly
Only have myself as admin
Enforce limited user agent support, demand everyone use a very specific browser and only allow that user agent on the site, this browser would not store any cached files on local disk
But… even with all of that … signal/keybase is much better on so many levels
سيكون رائعًا لو توفّر غلاف AutoCrypt لمنصة Discourse (أو منصة نشر غير متزامنة مشابهة)
فهو يدير «التعقيد» الخاص بـ PGP بشكل شفاف للمستخدم بطريقة آمنة. ومع ذلك، فإن وضع «الجهد الأفضل» لا يزال لا يوضح للمستخدم بشكل كافٍ أنه يسمح بالعودة إلى النص الصريح إذا لم تكن هناك تهيئة صريحة للغرفة.
نعم، أدرك الفرق بين تبادل المفاتيح والمفاتيح العامة خارج الحلقة. لكن هذا سيكون دون ثقة عمياء.
لا. المصادقة الثنائية ليست شبيهة بإدارة الهوية (مثل Shibboleth). هل تشير بشكل غير مباشر إلى «شيء أملكه وشيء أعرفه»؟ بمعنى أن تقديم دليل على امتلاكي لشيء ما يُعدّ بحد ذاته هوية؟
ستحتاج أيضًا إلى تأكيدات DANE.
هل تقصد حسابات «مجانية»؟
لقد فعلت Movim ذلك أيضًا، وهو ما دفعهم إلى التخلي عن OMEMO لمنصتهم الاجتماعية القائمة على XMPP.
مشروع على GitHub يستحق التأمل هو OverSec. ورغم أنه مخصص لأندرويد، إلا أن شخصًا ما قد يتحمل التحدي لتطويره لأندرويد.
–
سأفكّر أكثر في نماذج التهديد
ألا يكفي AutoCrypt؟
إن التسامح مع الشرور التي تُرتكب ضد الخصوصية قد خلق الأرضية للتهديدات الحالية. لا أعرف كيف أحل مشكلة اللامبالاة.
باستخدام هذا المنطق، أدعوهم إلى التوقف عن استخدام الإنترنت الذي هو أقدم بكثير.
البريد الإلكتروني، مثل XMPP وMatrix، موزع.
آمين. شكرًا لك.
لقد عطلت وضع الملخص لهذا السبب.
يجب إعادة تعليمهم حول هذا الأمر كما حدث مع حجب الإعلانات.