Um jetzt mal auf deiner Ebene zu argumentieren ist letzteres genauso Nonsens, denn mit "gültigen Zugangsdaten" (Root?) besorge ich mir einfach den nötigen Schlüssel um die gewünschten Daten auszulesen.
Deshalb hatte ich ja geschrieben dass es in
begrenztem Maße etwas bringen kann (aber nicht muss).
Wenn jemand root -Zugriff hat ist das Kind natürlich in den Brunnen gefallen, root kann alles.
Ich bin bei meiner Aussage allerdings von weniger weitreichenden Zugriffsrechten ausgegangen.
Nehmen wir z.B. an ein Co-Admin hat die Zugangsdaten für einen MySQL-User mit SELECT (aber nicht INSERT/UPDATE/DELETE) Rechten auf alle Tabellen einer XenForo-Datenbank und ein phpMyAdmin wo er diese nutzen kann.
Eine Verschlüsselung "at Rest" (egal ob Tablespace Encryption, LUKS, dm-crypt oder Whatever) bringt im diesem Fall gar nichts, der Co-Admin kann alles in allen Tabellen lesen und kriegt von der darunterliegenden Verschlüsselung nichts mit.
Liegen die Daten aber bereits in den Tabellen tlw. verschlüsselt vor (da der XenForo PHP-Code diese beim lesen ent- und beim schreiben wieder verschlüsselt) wird es bedeutend schwieriger:
Den Schlüssel hat XenForo, um diesen zu erhalten müsste er Zugriff auf den XenForo-Code erhalten.
Die Passwörter der XenForo-User sind verschlüsselt, da kommt er also nicht direkt weiter.
Sind auch Session-Ids verschlüsselt wird es auch da schwieriger anhand dieser eine Session mit ausreichenden Rechten zu übernehmen (was ohnehin als weitere Herausforderung hat dass diese an IPs gebunden sind).
Sind auch die TFA und User Remember Token verschlüsselt wird es schwieriger anhand dieser eine neue Session für einen berechtigten User zu erzeugen.
Summa summarum: Das dürften für den neugierigen 08/15 Co-Admin ausreichend hohe Hürden sein um diese nicht überwinden zu können - im Gegensatz zu einer Verschlüsselung "at Rest" die (s.o.) gar keine Hürde darstellt.
Insofern IMHO also weitaus weniger Nonsense
Speziell für Unterhaltungen gibt es sogar etwas in der Richtung:
[BS] High privacy
Soweit ich das sehe ist das genau dieser Ansatz, d.h. die Nachrichten werden von XenForo ent-/verschlüsselt - der Key liegt jedoch nicht im XenForo Code sondern beim User.
Aber wie Tealk ja schon geschrieben hat, entscheidet ist das Bedrohungsszenario dem vorgebeugt werden soll.
