Auf bitcoincashresearch.org streben wir ein gewisses Maß an Dezentralisierung des Forums an, einschließlich der Möglichkeit, dass jeder, der dies für notwendig hält, eine bestimmte Instanz des Forums unter einer anderen Domain neu aufbauen kann.
Damit dies möglich ist, sollten wir regelmäßig Backups der Datenbank veröffentlichen. Doch dabei stoßen wir auf das Problem, sensible Benutzerdaten wie E-Mail-Adressen, IP-Adressen usw. preiszugeben.
Wir könnten diese privaten Informationen manuell aus den Datenbank-Backups entfernen, doch das scheint nicht die klügste oder sauberste Lösung zu sein, insbesondere bei regelmäßigen Backups.
Ist Ihnen eine Lösung bekannt, die in dieser Hinsicht funktionieren könnte? Oder gibt es Beispiele für etwas Ähnliches, das bereits umgesetzt wurde?
Möchtest du IP-Adressen und E-Mail-Adressen entfernen? Ohne E-Mail-Adressen könnten Benutzer ihre Konten nicht wiederherstellen (wenn sie ein Passwort verwendet haben, könnten sie sich zwar anmelden, aber dann nicht ihre E-Mail-Adresse wieder hinzufügen, da es keine Möglichkeit gäbe, die Änderung zu validieren).
Ich sehe keine Möglichkeit, ein nützliches Backup zu erstellen, das nicht zumindest E-Mail-Adressen enthalten würde.
Ich stimme zu, dass es wie ein verrückter Sonderfall wirken könnte. Aber die Idee dahinter scheint nicht so abwegig, da sie darauf abzielt, die Zentralisierung von Foren zu vermeiden.
Ich verstehe, dass dies für einige Foren vielleicht nicht sehr wichtig ist, für andere jedoch schon.
Ich stimme auch zu, dass das Entfernen von Benutzern und Passwörtern (neben anderen Informationen) aus der Sicherungskopie verhindern würde, dass dieselben Benutzer sich bei der neuen Instanz anmelden können.
Deshalb habe ich gesagt, dass dies nicht der klügste Weg zu sein scheint.
Ich sollte meine Frage wahrscheinlich umformulieren.
Gibt es eine bekannte Methode oder ein empfohlenes Verfahren, um Datenbank-Sicherungen so zu veröffentlichen, dass jeder eine bestimmte Foren-Instanz neu aufbauen kann, ohne dabei private Informationen der Benutzer preiszugeben?
Ich möchte etwas Kontext hinzufügen. Es gibt einen sehr spezifischen Bedarf bzw. Anwendungsfall.
Es handelt sich um einen operativen Diskurs mit wichtigen Inhalten, die mit der Zeit noch an Bedeutung gewinnen werden. Aufgrund der Natur des Ökosystems, das ihn nutzt, haben wir gelernt, dass die Vermeidung von Single Points of Failure äußerst wichtig ist.
Bei einem heutigen Export, bei dem Authentifizierungsinformationen ausgeschlossen werden, ließe sich zwar der vollständige Site-Inhalt öffentlich veröffentlichen. Wie @pfaffman jedoch bereits anmerkte, führt dies zu einem irreversiblen Bruch: Nutzer können sich nicht mehr anmelden, und die exportierte Site wird schreibgeschützt.
Daher denke ich, dass Leandro eine Funktion in Discourse benötigt, die es Benutzern ermöglicht, sich über kryptografische Herausforderungen anstatt über traditionliche Konto-/Passwort-Verfahren anzumelden. Beim Export würde dann nur dieser Teil des Kontos enthalten sein – keine E-Mails, Passwort-Hashes usw. In der alternativen Kopie der Site könnten sich Nutzer, die diese Funktion genutzt haben, anmelden und ein Standard-Wiederherstellungsverfahren per E-Mail durchlaufen.
Bei dieser vollständigen Veröffentlichung ist es offensichtlich von größter Bedeutung, keine traditionellen Authentifizierungsinformationen wie E-Mail-Adressen oder Passwort-Hashes usw. aufzunehmen. Das ist so wichtig, dass bei jeder Version von Discourse mit dieser Funktion sensible Informationen getrennt vom restlichen Site-Datenbestand gespeichert werden sollten, um eine versehentliche Exportierung unmöglich zu machen.
Ich hoffe, das gibt etwas mehr Kontext zum Nachdenken.
Auch sind diese Änderungen offensichtlich alles andere als trivial. Es wäre gut, Feedback, Probleme und Alternativen zu hören. Vielleicht können auf unserer Ökosystem-Seite Ressourcen zusammengeführt werden, um einen Fork zu erstellen, der die Idee umsetzt.
Das kann erreicht werden, indem die Unterstützung für WebAuthn als passwortlose Authentifizierungsmethode hinzugefügt wird, wie im Beitrag WebAuthn-Unterstützung erläutert.
Das plus einen Dienst zur Bereinigung der Sicherungsdatei von den Feldern, die Sie nicht preisgeben möchten.
Übrigens müssen reguläre Benutzer E-Mail-Adressenänderungen nicht genehmigen, wenn sie eingeloggt sind. Daher wäre ein Datenbank-Dump ohne E-Mail-Adressen für alle Benutzer in Ordnung, die sich mit den im Datenbank gespeicherten Zugangsdaten anmelden sollen (das Passwort ist hier der einfachste Weg).
Ein Plugin, das entweder die E-Mail-Adressen entfernt oder verschlüsselt (ich denke, ich weiß, wie man das relativ einfach umsetzen kann), könnte das Problem lösen.
In einem Plugin habe ich einige Felder so verschlüsselt:
Ich denke, es könnte möglich sein, das UserEmail-Modell auf ähnliche Weise zu überschreiben und die E-Mail-Adressen zu verschlüsseln. Im UserEmail-Modell gibt es nicht viel Code, und ich vermute, dass es sich nur sehr selten ändert. Daher wäre eine solche Änderung möglicherweise nicht allzu riskant. Es könnte aber auch gar nicht funktionieren.
IP-Adressen herauszufiltern könnte etwas kniffliger sein, da ich denke, es wäre schwierig, das Benutzermodell zu überschreiben. Dafür könntest du ein Plugin erstellen, das diese IPs auf irgendeine Weise entfernt.
Eine weitere Möglichkeit, die am Horizont erscheint, ist die Verwendung eines Augmented PAKE (Passwort-authentifizierter Schlüsselaustausch), sodass das Passwort sowohl praktisch nicht aus der Datenbank wiederherstellbar ist als auch nie das Netzwerk berührt.
Leider befinden sich alle diese Verfahren noch fest im Bereich der experimentellen Kryptografie und sind nicht für eine einfache Bereitstellung bereit. iOS iCloud-Sync verwendet ein PAKE.
Wenn Sie die Anmeldung per E-Mail und Passwort beibehalten möchten, jedoch so, dass jeder auf das Konto eines beliebigen Benutzers in der gesicherten Datenbank zugreifen kann, können Sie dies erreichen, indem Sie für jeden Benutzer eine E-Mail-Adresse basierend auf dem Benutzernamen generieren, z. B. <username>@email.invalid.
Für Passwörter und Anmeldungen: Unter der Annahme, dass Discourse verschlüsselte Passwörter mit Salts verwendet (ich habe das nicht überprüft, gehe aber davon aus), können Sie ein Passwort wie 123456 (in Ihrer Live-Datenbank) festlegen, in der Datenbank die resultierende verschlüsselte Passwortversion sowie das Salt einsehen (anschließend ändern Sie Ihr Passwort wieder zurück oder führen dies an einem Testkonto durch). Führen Sie dann im neuen (geklonten) Datenbank eine Anweisung aus, um die verschlüsselten Passwörter und Salts aller Benutzer auf die zuvor eingesehenen Werte zu setzen (jeder Benutzer erhält dann dasselbe verschlüsselte Passwort sowie dasselbe Salt und folglich dasselbe Passwort, das Sie zuvor verwendet haben). Für einen Benutzer foo könnten Sie sich also mit der E-Mail-Adresse foo@email.invalid und dem Passwort 123456 anmelden.
Darüber hinaus sollten Sie eventuell die privaten Nachrichten löschen (falls diese nicht benötigt werden), da diese sensible Daten enthalten können.
Und schließlich ist es ratsam, nach Feldern zu suchen, die vertrauliche Daten enthalten könnten, wie z. B. die (Administrator-)Einstellungen.