我想对我的简单系统中的用户数据进行匿名化。每个用户都有两个文件,例如-1.json和-2.json。
我希望将它们存储在所有用户文件的某个存储库中(存储库是安全的)。我希望将文件移动到这个存储库中,并将用户ID编号匿名化(没有通过文件名接收ID的选项),我希望使用不同的哈希函数来创建新的文件名,这样没有人能够理解这两个文件连接到一个用户。
The目标:
我想出了一些解决这种情况的方法:
SHA512(<40-characters-suffix1>),第二个文件:SHA512(<40-characters-suffix2>)multiple times AES(, ),第二个文件:multiple times AES(, )用哪种方式更好?还有更好的方法吗?
发布于 2018-01-07 16:16:56
我会使用第一种系统,与AES系统没有明显的区别;但是您仍然需要考虑其他可能无关的因素。
UPDATE:再考虑一下,您可能希望使用PKDBF2作为“散列”,以减少成功强制执行的可能性。
如果后缀是已知的,或者通常在用户ID和哈希之间存在已知的映射,那么攻击者可以简单地枚举所有可能的ID。
例如,攻击者知道ID从1开始,最多为10万;即使使用CPU和内存硬算法,为所有可能的用户ID生成散列并将它们存储到数据库中也不会超过几天。使用SHA1或AES,只需几分钟,甚至几秒钟。之后,要知道在给定的散列后面隐藏了什么ID,只需在列表中查找那个哈希。
您可能需要考虑用随机ID替换顺序ID(这可能会在下面的区域造成痛苦;您需要处理随机newId与尚未替换的oldId发生碰撞的情况)。此时,“可能的ID”不再是10万(从1到100,000),而是几十亿万亿(从0x0000000000000000000000000000到0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF强暴现在将花费不可能的时间和/或一个不可能的大型数据库来保存散列。
考虑file1和file2之间存在非平凡关联的可能性。虽然微不足道的关联可能是包含唯一标识符的两个文件,或者更糟的是包含用户ID副本的文件,但在这两个文件中可能都有信息允许确定用户ID或配对文件之间的链接;例如,某个资源的时间戳或可逆UUID。
此问题可能扩展到元数据,如mtime、inode编号或目录列表中的位置;在同一秒钟内创建或存储的两个文件可以跟踪到同一个用户,即使其中一个无法反算用户ID。
您应该考虑将文件归档为2或3深的结构,即
/rootdir/ae/02/47/ae0247f19a8b52f.json并使用非自动更新文件系统;和/或当您更改、创建或删除文件时,将整个分支(在这里为ae/02、ae/02/47和ae/02/47/ae0247f19a8b52f.json)设置为一个固定时间,例如1970年1月1日午夜。
当将文件传输到存储库时,您可能希望首先生成一个列表:
000001-1.json aae3799a82b9fb8ccd34c1d5aa6565b2
000001-2.json 539c50984894084b3e3b1047eee187ae
...然后你把名单弄乱。一旦这样做,对于列表中的每一对,您将移动例如000001-2.json到repositoryRoot/53/9c/50/539c50984894084b3e3b1047eee187ae。这样,000001-1.json和000001-2.json的inode、文件系统位置或磁盘物理位置之间就没有关联了。
请注意,在大多数文件系统上,这种方法会显著增加复制所需的时间。
从安全性的角度来看,这看起来并不是很有希望,因为电子邮件通常是可以猜测和/或回收的。这在很大程度上取决于这些JSON文件到底存储了什么,以及攻击场景实际上是什么(黑客访问一个尴尬信息的存储库并试图敲诈所有者的情况--因此需要从JSON返回到电子邮件--以及试图获取已知其电子邮件的受害者的信息的人将被处理得非常不同)。
一种可能是将匿名表保存在存储库之外:
ID RandomToken
lserni@gmail.com 5231b225ea0dbcced14c993523af4986
.... ....此时,您可以使用令牌作为“秘密”密码。
https://security.stackexchange.com/questions/176959
复制相似问题