Su bitcoincashresearch.org stiamo cercando di offrire un certo livello di decentralizzazione del forum, inclusa la possibilità che chiunque lo ritenga necessario possa ricreare un’istanza del forum su un altro dominio.
Affinché ciò sia possibile, dovremmo pubblicare periodicamente i backup del database. Tuttavia, ci troviamo di fronte al problema di esporre le informazioni private degli utenti, come indirizzi email, indirizzi IP, ecc.
Potremmo rimuovere manualmente tali informazioni private dai backup del database, ma non sembra l’opzione più intelligente o ordinata, specialmente nel caso di backup periodici.
Siete a conoscenza di qualche soluzione che possa funzionare in tal senso? O di qualche esempio di qualcosa di simile che sia già stato realizzato?
Vuoi rimuovere gli indirizzi IP e gli indirizzi email? Senza gli indirizzi email, non ci sarebbe alcun modo per gli utenti di recuperare i propri account (se usassero una password, potrebbero accedere, ma non potrebbero reinserire il proprio indirizzo email, poiché non ci sarebbe alcun modo di validare la modifica).
Non vedo alcun modo per creare un backup utile che non includa almeno gli indirizzi email.
Sono d’accordo sul fatto che possa sembrare un caso limite bizzarro. Tuttavia, l’idea alla base non mi sembra così irrazionale, dato che mira a evitare la centralizzazione del forum.
Capisco che questo possa non essere molto importante per alcuni forum, ma potrebbe esserlo per altri.
Concordo anche sul fatto che rimuovere utenti e password (tra le altre informazioni) dal backup impedirebbe a quegli stessi utenti di accedere alla nuova istanza.
Ecco perché ho detto che non sembrava il modo più intelligente.
Dovrei probabilmente riformulare la mia domanda.
Esiste un metodo noto o una procedura consigliata per pubblicare backup del database in modo che chiunque possa ricreare un’istanza specifica del forum senza esporre le informazioni private degli utenti?
Vorrei aggiungere un po’ di contesto. C’è un caso d’uso molto specifico.
Esiste un discorso operativo che contiene informazioni importanti e il cui contenuto diventerà sempre più rilevante nel tempo. Data la natura dell’ecosistema che lo utilizza, abbiamo imparato che è fondamentale evitare punti singoli di fallimento.
Con un’exportazione odierna, se si escludono le informazioni di autenticazione, dovrebbe essere possibile pubblicare pubblicamente l’intero contenuto del sito; tuttavia, come ha giustamente osservato @pfaffman, si finisce per creare una rottura irreversibile in cui gli utenti non possono più autenticarsi e il sito esportato diventa in sola lettura.
Pertanto, penso che ciò di cui Leandro abbia bisogno sia una funzionalità in Discourse che permetta agli utenti di accedere tramite sfide crittografiche, anziché tramite i tradizionali schemi di account e password. Nell’export, includerebbe solo questa parte dell’account, escludendo email, hash delle password e altre informazioni simili. Nella copia alternativa del sito, gli utenti che hanno sfruttato questa funzionalità potrebbero accedere e seguire una procedura di recupero account standard tramite email.
Durante questa pubblicazione completa, sarà ovviamente fondamentale non includere alcuna informazione tradizionale di autenticazione dell’account, come indirizzi email e hash delle password, ecc. È così importante che, per qualsiasi versione di Discourse con questa funzionalità, le informazioni sensibili debbano essere conservate in un luogo separato rispetto al resto dei dati del sito, rendendo impossibile esportarle per errore.
Spero che questo aggiunga un po’ di contesto su cui riflettere.
Inoltre, queste modifiche sono ovviamente molto complesse. Sarebbe utile ricevere feedback, segnalazioni di problemi e proposte alternative. Forse si potrebbero riunire risorse all’interno del nostro ecosistema per creare un fork che implementi l’idea.
Ah, e gli utenti normali non devono approvare le modifiche all’indirizzo email se sono già loggati, quindi un dump con gli indirizzi email rimossi va bene per tutti gli utenti che dovrebbero accedere con le credenziali presenti nel database (la password è la soluzione più semplice).
Un plugin che rimuovesse gli indirizzi email o li criptasse (penso di sapere come farlo con una ragionevole facilità) potrebbe risolvere il problema.
In un plugin ho criptato alcuni campi in questo modo:
Penso che potrebbe essere possibile sovrascrivere il modello UserEmail in modo simile e criptare gli indirizzi email. Nel modello UserEmail non c’è molto codice e sospetto che cambi molto raramente, quindi potrebbe non essere una modifica troppo pericolosa. Oppure potrebbe non funzionare affatto.
Filtrare gli indirizzi IP potrebbe essere un po’ più complicato, poiché penso che sarebbe difficile sovrascrivere il modello utente. Per questo potresti creare un plugin che rimuova quegli indirizzi IP in un modo o nell’altro.
Un’altra possibilità all’orizzonte è l’uso di un PAKE (Password-Authenticated Key Exchange) aumentato, in modo che la password sia praticamente irrecuperabile dal database e non venga mai trasmessa sulla rete.
Purtroppo, sono tutti ancora saldamente nel regno della crittografia sperimentale e non pronti per una distribuzione semplice. La sincronizzazione di iOS iCloud utilizza un PAKE.
Se desideri mantenere il login tramite email e password, ma in modo che chiunque possa accedere all’account di qualsiasi utente nel database di backup, puoi ottenere ciò generando un’email basata sul nome utente per ogni utente, ad esempio <username>@email.invalid.
Per quanto riguarda le password e i login, assumendo che Discourse utilizzi password crittografate con salt (non l’ho verificato, ma lo presumo), puoi impostare una password come 123456 (nel tuo database attivo), visualizzare nel database la password crittografata risultante insieme al salt (poi cambia di nuovo la password o fallo su un account fittizio), quindi esegui un comando nel nuovo database (clonato) per impostare le password crittografate e i salt di ogni utente ai valori che hai visto prima (ogni utente avrà la stessa password crittografata e lo stesso salt, e di conseguenza la stessa password, quella che hai utilizzato prima). Quindi, per un utente foo, potrai accedere con l’email foo@email.invalid e la password 123456.
Oltre a questo, potresti voler eliminare i messaggi privati (se non sono necessari), poiché potrebbero contenere dati sensibili.
Infine, è buona norma verificare i campi che potrebbero contenere dati confidenziali, come le impostazioni (amministrative).