En bitcoincashresearch.org buscamos ofrecer cierto nivel de descentralización del foro, incluyendo la posibilidad de que cualquier persona que lo considere necesario pueda reconstruir una instancia determinada del foro en otro dominio.
Para que esto sea posible, deberíamos publicar copias de seguridad de la base de datos periódicamente. Sin embargo, nos enfrentamos al problema de exponer información privada de los usuarios, como correos electrónicos, direcciones IP, etc.
Podríamos eliminar esa información privada de las copias de seguridad de la base de datos manualmente, pero no parece ser la opción más inteligente ni más limpia, especialmente con copias de seguridad periódicas.
¿Conoce alguna solución que pueda funcionar en este sentido? ¿O algún ejemplo de algo similar que se haya hecho?
¿Te gustaría eliminar las direcciones IP y las direcciones de correo electrónico? Sin direcciones de correo electrónico, no habría forma de que los usuarios recuperen sus cuentas (si usaron una contraseña, podrían iniciar sesión, pero luego no podrían volver a ingresar su dirección de correo electrónico, ya que no habría forma de validar el cambio).
No veo ninguna forma de crear una copia de seguridad útil que no incluya al menos las direcciones de correo electrónico.
Estoy de acuerdo en que podría parecer un caso límite extraño. Pero la idea detrás de ello no parece tan descabellada, ya que busca evitar la centralización del foro.
Entiendo que esto puede no ser muy importante para algunos foros, pero sí puede serlo para otros.
También estoy de acuerdo en que eliminar usuarios y contraseñas (entre otra información) de la copia de seguridad impediría que esos mismos usuarios inicien sesión en la nueva instancia.
Por eso dije que no parecía la forma más inteligente de hacerlo.
Probablemente debería reformular mi pregunta.
¿Existe alguna forma conocida o procedimiento recomendado para publicar copias de seguridad de la base de datos de modo que cualquiera pueda reconstruir una instancia dada del foro sin exponer la información privada de los usuarios?
Me gustaría agregar algo de contexto. Hay una necesidad / caso de uso muy específico.
Existe un discurso operativo que contiene información importante y cuyo contenido será cada vez más relevante con el tiempo. Debido a la naturaleza del ecosistema que lo utiliza, hemos aprendido que es muy importante evitar los puntos únicos de fallo.
Con una exportación actual, si se excluye la información de autenticación, debería ser posible publicar públicamente todo el contenido del sitio, pero como señaló @pfaffman, terminas con una ruptura irreversible donde los usuarios ya no pueden autenticarse y el sitio exportado se vuelve de solo lectura.
Por lo tanto, creo que lo que Leandro necesita es una función en Discourse que permita a los usuarios iniciar sesión mediante desafíos criptográficos en lugar de los esquemas tradicionales de cuenta/contraseña. Luego, en la exportación, solo se incluiría esa parte de la cuenta: nada de los demás correos electrónicos, hashes de contraseñas, etc. En la copia alternativa del sitio, los usuarios que aprovecharon esta función podrán iniciar sesión y seguir un procedimiento de recuperación de cuenta estándar o por correo electrónico.
Al realizar esa publicación completa, será obviamente muy importante no incluir ninguna de la información tradicional de autenticación de cuentas, como correos electrónicos y hashes de contraseñas, etc. Es tan importante que, para cualquier versión de Discourse con esta función, la información sensible debe mantenerse en un lugar separado del resto de los datos del sitio, de modo que sea imposible exportarla por error.
Espero que esto proporcione un poco más de contexto para reflexionar.
Además, estos cambios son obviamente muy complejos. Sería bueno recibir comentarios, problemas y alternativas. Tal vez se puedan reunir recursos en nuestro lado del ecosistema para crear un fork que implemente la idea.
Ah, y los usuarios regulares no necesitan aprobar los cambios de dirección de correo electrónico si ya han iniciado sesión, por lo que un volcado de datos sin direcciones de correo electrónico sería aceptable para todos los usuarios que deban iniciar sesión con las credenciales que haya en la base de datos (la contraseña es lo más sencillo).
Un plugin que eliminara las direcciones de correo electrónico o las cifrara (creo que sé cómo hacerlo con relativa facilidad) resolvería el problema.
En un plugin he cifrado algunos campos de la siguiente manera:
Creo que podría ser posible sobreescribir el modelo UserEmail de forma similar y cifrar las direcciones de correo electrónico. No hay mucho código en el modelo UserEmail y sospecho que cambia muy poco, por lo que podría no ser un cambio demasiado peligroso. O quizás no funcione en absoluto.
Filtrar las direcciones IP podría ser un poco más complicado, ya que creo que sería difícil sobreescribir el modelo de usuario. Para ello, podrías crear un plugin que elimine esas direcciones IP de una forma u otra.
Otra posibilidad que se perfila es el uso de un PAKE (Intercambio de Clave Autenticada con Contraseña) aumentado, de modo que la contraseña sea prácticamente irrecuperable desde la base de datos y nunca transite por la red.
Lamentablemente, todas estas soluciones siguen estando firmemente en el ámbito de la criptografía experimental y no están listas para una implementación sencilla. La sincronización de iCloud en iOS utiliza un PAKE.
Si deseas mantener el inicio de sesión con correo electrónico y contraseña, pero de manera que cualquier persona pueda acceder a la cuenta de cualquier usuario en la base de datos respaldada, puedes lograrlo generando un correo electrónico basado en el nombre de usuario para cada usuario, como <username>@email.invalid.
En cuanto a las contraseñas y los inicios de sesión, suponiendo que Discourse utiliza contraseñas cifradas con sal (no lo he verificado, pero lo asumo), puedes definir una contraseña como 123456 (en tu base de datos en vivo), consultar en la base de datos la contraseña cifrada resultante junto con la sal (luego cambia tu contraseña de nuevo, o hazlo en una cuenta falsa), y luego ejecutar una instrucción en la nueva base de datos (clonada) para definir las contraseñas cifradas y las sales de cada usuario con los valores que observaste anteriormente (cada usuario tendrá la misma contraseña cifrada y la misma sal, y, en consecuencia, la misma contraseña, la que usaste antes). Así, para un usuario foo, podrías iniciar sesión con el correo electrónico foo@email.invalid y la contraseña 123456.
Además de eso, es posible que desees eliminar los mensajes privados (si no son necesarios), ya que pueden contener datos sensibles.
Y finalmente, es recomendable revisar los campos que podrían contener datos confidenciales, como la configuración (de administrador).