Sur bitcoincashresearch.org, nous souhaitons offrir un certain niveau de décentralisation au forum, y compris la possibilité pour toute personne qui le juge nécessaire de recréer une instance du forum sur un autre domaine.
Pour que cela soit possible, nous devrions publier régulièrement des sauvegardes de la base de données. Cependant, nous faisons face au problème de l’exposition des informations privées des utilisateurs, telles que les adresses e-mail, les adresses IP, etc.
Nous pourrions supprimer manuellement ces informations privées des sauvegardes de la base de données, mais cela ne semble pas être l’option la plus intelligente ou la plus élégante, d’autant plus avec des sauvegardes périodiques.
Connaissez-vous une solution qui pourrait fonctionner dans ce contexte ? Ou un exemple similaire qui a déjà été réalisé ?
Souhaitez-vous supprimer les adresses IP et les adresses e-mail ? Sans adresses e-mail, les utilisateurs ne pourraient pas récupérer leurs comptes (s’ils ont utilisé un mot de passe, ils pourraient se connecter, mais ils ne pourraient pas remettre leur adresse e-mail, car il n’y aurait aucun moyen de valider la modification).
Je ne vois aucun moyen de créer une sauvegarde utile qui ne contienne pas au moins les adresses e-mail.
Je reconnais que cela peut sembler être un cas limite étrange. Mais l’idée derrière cela ne me paraît pas si farfelue, car elle vise à éviter la centralisation des forums.
Je comprends que cela puisse ne pas être très important pour certains forums, mais cela peut l’être pour d’autres.
Je suis également d’accord pour dire que supprimer les utilisateurs et les mots de passe (entre autres informations) des sauvegardes empêcherait ces mêmes utilisateurs de se connecter à la nouvelle instance.
C’est pourquoi j’ai dit que cela ne semblait pas être la méthode la plus judicieuse.
Je devrais probablement reformuler ma question.
Existe-t-il une méthode connue ou une procédure recommandée pour publier des sauvegardes de base de données afin que n’importe qui puisse reconstruire une instance donnée du forum sans exposer les informations privées des utilisateurs ?
Je souhaiterais ajouter un peu de contexte. Il existe un besoin ou un cas d’usage très spécifique.
Il s’agit d’un discours opérationnel contenant des informations importantes, dont l’importance ne fera que croître avec le temps. En raison de la nature de l’écosystème qui l’utilise, nous avons appris qu’il est crucial d’éviter les points de défaillance uniques.
Avec une exportation actuelle, si vous excluez les informations d’authentification, il devrait être possible de publier publiquement l’intégralité du contenu du site. Cependant, comme l’a souligné @pfaffman, cela entraîne une rupture irréversible : les utilisateurs ne peuvent plus s’authentifier et le site exporté devient en lecture seule.
Par conséquent, je pense que ce dont Leandro a besoin, c’est d’une fonctionnalité dans Discourse permettant aux utilisateurs de se connecter via des défis cryptographiques plutôt que par des méthodes traditionnelles de compte/mot de passe. Ensuite, lors de l’exportation, n’inclure que cette partie du compte — aucune des autres informations comme l’adresse e-mail, les hachages de mots de passe, etc. Dans la copie alternative du site, les utilisateurs ayant bénéficié de cette fonctionnalité pourront désormais se connecter et suivre une procédure de récupération de compte standard par e-mail.
Lors de cette publication complète, il sera évidemment très important de ne inclure aucune information d’authentification traditionnelle, comme les adresses e-mail ou les hachages de mots de passe, etc. C’est si important que, pour toute version de Discourse incluant cette fonctionnalité, les informations sensibles doivent être conservées dans un emplacement séparé du reste des données du site, afin qu’il soit impossible de les exporter par erreur.
J’espère que cela vous donne un peu plus de contexte à réfléchir.
De plus, ces modifications sont évidemment très complexes. Il serait bon de recueillir des retours, des problèmes et des alternatives. Peut-être que des ressources pourraient être réunies de notre côté de l’écosystème pour créer une branche qui implémente l’idée.
Cela peut être réalisé en ajoutant le support de WebAuthn en tant que méthode d’authentification sans mot de passe, comme expliqué dans Support de WebAuthn.
Cela, ainsi qu’un service pour nettoyer le fichier de sauvegarde des champs que vous ne souhaitez pas exposer.
Ah, et les utilisateurs réguliers n’ont pas besoin d’approuver les modifications d’adresse e-mail s’ils sont connectés, donc un dump avec les adresses e-mail supprimées conviendrait à tous les utilisateurs qui doivent se connecter avec n’importe quelles informations d’identification présentes dans la base de données (le mot de passe est le plus simple).
Un plugin qui supprimerait les adresses e-mail ou les chiffrerait (je pense savoir comment le faire assez facilement) résoudrait le problème.
Dans un plugin, j’ai chiffré certains champs de cette manière :
Je pense qu’il serait possible de surcharger le modèle UserEmail de manière similaire pour chiffrer les adresses e-mail. Il n’y a pas beaucoup de code dans le modèle UserEmail et je soupçonne qu’il change très rarement, donc cela pourrait ne pas être trop dangereux. Ou alors, cela pourrait ne pas fonctionner du tout.
Filtrer les adresses IP pourrait être un peu plus délicat, car je pense qu’il serait difficile de surcharger le modèle utilisateur. Pour cela, vous pourriez créer un plugin qui supprime ces adresses IP d’une manière ou d’une autre.
@Falco et @pfaffman, un grand merci pour vos retours et conseils.
Nous allons examiner WebAuthn pour voir si nous pouvons emprunter cette voie, de même pour votre plugin @pfaffman.
Je reviendrai vers vous dans quelques jours avec des commentaires, des questions ou des conclusions.
Une autre possibilité qui se profile est l’utilisation d’un PAKE (échange de clés authentifié par mot de passe) augmenté, afin que le mot de passe soit à la fois pratiquement irrécupérable depuis la base de données et ne transite jamais sur le réseau.
Malheureusement, toutes ces solutions restent fermement dans le domaine de la cryptographie expérimentale et ne sont pas encore prêtes pour un déploiement facile. La synchronisation iCloud sur iOS utilise un PAKE.
Si vous souhaitez conserver la connexion par e-mail/mot de passe, mais de manière à ce que n’importe qui puisse accéder au compte de n’importe quel utilisateur dans la base de données sauvegardée, vous pouvez y parvenir en générant un e-mail basé sur le nom d’utilisateur pour chaque utilisateur, par exemple <nom d'utilisateur>@email.invalid.
Pour les mots de passe et les connexions, en supposant que Discourse utilise des mots de passe chiffrés avec des selles (je n’ai pas vérifié, mais je le suppose), vous pouvez définir un mot de passe comme 123456 (dans votre base de données en direct), consulter dans la base de données le mot de passe chiffré résultant ainsi que la selle (puis remettez votre mot de passe tel quel, ou faites-le sur un compte factice), puis exécutez une commande dans la nouvelle base de données (clonée) pour définir les mots de passe chiffrés et les selles de chaque utilisateur sur les valeurs que vous avez observées précédemment (chaque utilisateur aura le même mot de passe chiffré ainsi que la même selle, et par conséquent, le même mot de passe, celui que vous avez utilisé précédemment). Ainsi, pour un utilisateur foo, vous pourrez vous connecter avec l’e-mail foo@email.invalid et le mot de passe 123456.
Autre chose, vous voudrez peut-être supprimer les messages privés (s’ils ne sont pas nécessaires), car ils peuvent contenir des données sensibles.
Enfin, il est bon de vérifier les champs pouvant contenir des données confidentielles, comme les paramètres (d’administration).