在 bitcoincashresearch.org,我们致力于提供一定程度的论坛去中心化,包括允许任何认为有必要的人在其他域名上重建某个论坛实例的可能性。
为此,我们需要定期发布数据库备份。但我们面临一个难题:如何避免泄露用户的私人信息,例如电子邮件地址、IP 地址等。
我们可以手动从数据库备份中删除这些私人信息,但这似乎并非最明智或最整洁的方案,尤其是在进行周期性备份的情况下。
您是否了解任何可以解决此类问题的方案?或者是否有类似的案例可供参考?
在 bitcoincashresearch.org,我们致力于提供一定程度的论坛去中心化,包括允许任何认为有必要的人在其他域名上重建某个论坛实例的可能性。
为此,我们需要定期发布数据库备份。但我们面临一个难题:如何避免泄露用户的私人信息,例如电子邮件地址、IP 地址等。
我们可以手动从数据库备份中删除这些私人信息,但这似乎并非最明智或最整洁的方案,尤其是在进行周期性备份的情况下。
您是否了解任何可以解决此类问题的方案?或者是否有类似的案例可供参考?
这真是一个相当奇怪的边界情况!
你是否希望移除 IP 地址和电子邮件地址?如果没有电子邮件地址,用户将无法找回他们的账户(如果他们使用密码,可以登录,但随后将无法重新添加电子邮件地址,因为无法验证该更改)。
我看不到有任何方法可以创建不包含至少电子邮件地址的有用备份。
以下是 Discourse 论坛的公开 SQL 转储文件:Index: if-archive/info/intficforum
你可以从中获取一些灵感。
我同意这看起来可能像是一个奇怪的边缘情况。但其背后的理念并非如此,因为它有助于避免论坛的集中化。
我理解这对某些论坛来说可能不太重要,但对其他论坛来说可能至关重要。
我也同意,从备份中移除用户和密码(以及其他信息)会阻止这些用户登录到新实例。
这就是为什么我说这似乎不是最明智的做法。
我或许应该重新表述我的问题。
是否有已知的方法或推荐的做法,可以在发布数据库备份时,让任何人能够重建某个论坛实例,同时不泄露用户的隐私信息?
我想补充一些背景信息。这里有一个非常具体的需求/用例。
存在一种运营层面的讨论,其内容至关重要,且随着时间的推移,其重要性将日益凸显。由于使用该内容的生态系统特性,我们已认识到避免单点故障极为关键。
就目前的导出功能而言,如果排除认证信息,理论上可以公开发布整个站点的内容。但正如 @pfaffman 指出的那样,这会导致一个不可逆的断裂:用户将无法再登录,导出的站点将变为只读状态。
因此,我认为 Leandro 需要的是 Discourse 的一项功能,允许用户通过加密挑战而非传统的账号/密码方案进行登录。在导出时,仅包含该部分账户信息,而不包含其他如电子邮件、密码哈希等数据。在站点的备用副本中,利用该功能的用户现在可以登录,并通过电子邮件或标准账户恢复流程进行验证。
在进行完整发布时,显然非常重要的一点是,不要包含任何传统的账户认证信息(如电子邮件和密码哈希等)。这一点至关重要,因此对于任何具备此功能的 Discourse 版本,敏感信息应与站点其他数据分开存储,以确保不可能被意外导出。
希望这能提供更多可供思考的背景信息。
此外,这些改动显然非常复杂。我们很希望能听到反馈、问题以及替代方案。或许我们可以整合生态系统方面的资源,创建一个实现该想法的分支。
这可以通过添加对 WebAuthn 作为无密码认证方式的支持来实现,正如 WebAuthn 支持 中所解释的那样。
此外,还需要一项服务来清理备份文件中您不想暴露的字段。
这是另一种登录解决方案。
另外,如果普通用户已登录,则无需批准电子邮件地址的更改。因此,只要移除电子邮件地址,这样的数据库转储对于所有应使用数据库中凭据(密码最简单)登录的用户来说都是可行的。
可以开发一个插件,要么直接移除电子邮件地址,要么对电子邮件地址进行加密(我想我知道如何相对容易地实现这一点),从而解决该问题。
在我开发的一个插件中,我曾按如下方式加密某些字段:
我认为类似地覆盖 UserEmail 模型并加密电子邮件地址也是可行的。UserEmail 模型中的代码量不大,而且我怀疑它很少变更,因此这样的改动可能并不太危险。当然,也可能完全无法奏效。
过滤 IP 地址可能会更棘手一些,因为我认为很难覆盖用户模型。对此,你可以开发一个插件,以某种方式移除这些 IP 地址。
另一个可行的方向是采用增强型 PAKE(密码认证密钥交换),这样密码既在数据库中几乎无法被恢复,也绝不会在传输过程中暴露。
遗憾的是,这些方案目前仍属于实验性密码学范畴,尚未准备好进行便捷部署。iOS 的 iCloud 同步功能采用了 PAKE 技术。
如果您希望保留邮箱/密码登录方式,但允许任何人访问备份数据库中任意用户的账户,可以通过为每个用户生成一个基于用户名的邮箱来实现,例如 <username>@email.invalid。
关于密码和登录,假设 Discourse 使用带盐值的加密密码(我尚未确认,但推测如此),您可以先在实时数据库中设置一个如 123456 的密码,然后在数据库中查看生成的加密密码及其对应的盐值(之后可将密码改回,或在测试账户中操作)。接着,在新克隆的数据库中执行一条指令,将所有用户的加密密码和盐值统一设置为您之前看到的值。这样,每个用户都将拥有相同的加密密码和盐值,从而使用相同的密码(即您之前使用的密码)。例如,对于用户 foo,您可以使用邮箱 foo@email.invalid 和密码 123456 登录。
除此之外,您可能还需要删除私信(如果不需要),因为它们可能包含敏感数据。
最后,建议检查可能包含机密信息的字段,例如(管理员)设置项。