【发布时间】:2017-05-09 18:32:21
【问题描述】:
是否可以在不明确显示其关系或所有者的情况下将相关数据存储在数据库中? This page 讨论使用用户信息的哈希值和密码来识别交易所属的用户。一些搜索未发现此安全功能的实施细节。
假设我的用户将私人数据绑定到他们的帐户,我怎样才能使有权访问数据库转储的人无法分辨哪些数据属于哪个用户?
【问题讨论】:
标签: database security database-design hash
是否可以在不明确显示其关系或所有者的情况下将相关数据存储在数据库中? This page 讨论使用用户信息的哈希值和密码来识别交易所属的用户。一些搜索未发现此安全功能的实施细节。
假设我的用户将私人数据绑定到他们的帐户,我怎样才能使有权访问数据库转储的人无法分辨哪些数据属于哪个用户?
【问题讨论】:
标签: database security database-design hash
这不是一种安全功能,它是一种设计模式(或者,可以说是反模式)。您链接的页面描述了他们如何实现它:敏感信息与一个标识符一起存储,如果没有交叉引用数据库外部的信息,就无法追溯到任何给定用户。在他们的示例中,它是密码,当与其他帐户信息结合并经过哈希处理时,会为该用户的交易生成一致的 ID。为了正确地将用户与其交易相关联,您需要原始密码来重建哈希。没有密码 = 没有关联。
这样就可以了;它牺牲了参照完整性,这就是我称之为反模式的原因,但这就是整个想法。更大的问题是它可能是最敏感的点,因为每当用于生成哈希的信息发生变化时,必须为用户的所有交易更新哈希。缺乏外键约束也允许没有任何用户的虚假交易。从结构上讲,拥有一个与交易表具有适当外键关系的匿名交易所有者表以及将所有者实体与实际用户联系起来的散列会更安全一些。这样,敏感关系是一对一而不是一对多,并且完整性失败的影响受到限制。
当然,这两种方法都容易受到简单的耐心和分析的影响——如果有人有数据库转储并且有足够的动力,只要交易本身就足以了解是谁制作的重新绑定到一致的用户哈希或所有者。一份披萨送货费可以是任何东西;有几个把你放在离某人家几英里的地方。您可以与匿名记录关联的信息越多,它的匿名性就越低。
【讨论】: