用户身份匿名化

信息安全哈希匿名

2021-08-26 04:16:14

我想在我的简单系统中对用户数据进行匿名化。每个用户有两个文件，例如<id-number>-1.json和<id-number>-2.json。

我想将它们存储在所有用户文件的某个存储库中（存储库是安全的）。我想将文件移动到这个存储库并匿名化用户 ID 号（没有通过文件名接收 ID 的选项），并且我想用不同的散列函数制作新文件名，这样没人能理解这两个文件连接到一个用户。

目标：

能够通过用户 ID 访问这两个文件。
其他人即使看到一个文件名也无法识别所有者用户。
看到这两个文件名的其他人将无法知道它们属于同一用户。

对于这种情况，我想了一些解决方案：

第一个文件：SHA512(<id-number><40-characters-suffix1>)，第二个文件：SHA512(<id-number><40-characters-suffix2>)
第一个文件：multiple times AES(<constant-long-string>, <id-number-as-key>)，第二个文件：multiple times AES(<other-constant-long-string>, <id-number-as-key>)

哪种方式更好用？还有另一种更好的方法吗？

1个回答

我会使用第一个系统，与 AES 没有显着差异；但您仍然需要考虑其他可能不相关的因素。

更新：再三考虑，您可能希望将PKDBF2用作“哈希”，以减少成功进行暴力破解的机会。

蛮力攻击

如果后缀是已知的，或者通常用户 ID 和哈希之间存在已知的映射，那么攻击者可以简单地枚举所有可能的 ID。

例如，攻击者知道ID从1开始，最多为100,000；即使使用 CPU 和内存硬算法，为所有可能的用户 ID 生成哈希并将它们存储到数据库中也不会超过几天。使用 SHA1 或 AES，只需几分钟，甚至几秒钟。之后，要知道给定散列后面隐藏了什么 ID，只需在列表中查找该散列即可。

您可能需要考虑将顺序 ID 替换为随机 ID（这在下层区域可能会很痛苦；并且您需要处理随机 newId 与尚未替换的 oldId 冲突的情况）。那时，“可能的 ID”不再是十万（从 1 到 100,000）而是数十亿万亿（从 0x00000000000000000000000000000000 到 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF）。暴力破解现在将花费不可能的时间，和/或不可能的大数据库来保存哈希。

相关性

考虑 file1 和 file2 之间存在非平凡相关的可能性。虽然一个微不足道的相关性可能是两个文件都包含一个唯一标识符，或者更糟糕的是，用户 ID 的副本，但两个文件中可能都有可以确定用户 ID 或配对文件之间的链接的信息；例如，时间戳或某些资源的可逆 UUID。

此问题可能会扩展到元数据，例如 mtime、inode 编号或目录列表中的位置；在同一秒内创建的两个文件或一个接一个地存储的两个文件可以被跟踪到同一个用户，即使一个人无法反算用户 ID。

您应该考虑将文件归档为 2 或 3 深的结构，即

/rootdir/ae/02/47/ae0247f19a8b52f.json

并使用非实时更新文件系统；和/或当您更改或创建或删除文件时，touch整个分支（此处为 ae、ae/02、ae/02/47 和 ae/02/47/ae0247f19a8b52f.json）到一个固定的日期时间，例如 1 月午夜1970 年第 1 次。

初始化回购

将文件传输到存储库时，您可能希望首先生成一个列表：

 000001-1.json      aae3799a82b9fb8ccd34c1d5aa6565b2
 000001-2.json      539c50984894084b3e3b1047eee187ae
 ...

然后你打乱名单。完成此操作后，对于列表中的每一对，您将移动000001-2.json到repositoryRoot/53/9c/50/539c50984894084b3e3b1047eee187ae. 000001-1.json这样，和的 inode、文件系统位置或磁盘物理位置之间将没有关联000001-2.json。

请注意，在大多数文件系统上，这种方法会明显增加进行复制所需的时间。

电子邮件作为 ID

这在安全方面看起来不太有希望，因为电子邮件通常是可以猜测和/或回收的。很大程度上取决于这些 JSON 文件中究竟存储了什么以及实际的攻击场景是什么（黑客获得了对尴尬信息存储库的访问权并试图勒索所有者的两种情况 - 因此需要从 JSON 恢复到电子邮件 - 以及试图获取已知电子邮件的受害者信息的人的处理方式将大不相同）。

一种可能性是在存储库之外保存一个匿名表：

ID                   RandomToken
lserni@gmail.com     5231b225ea0dbcced14c993523af4986
....                 ....

那时您可以使用令牌作为“秘密”密码。

其它你可能感兴趣的问题