在客户端加密数据库主键以进行模糊处理

时间:2017-08-06 06:53:58

标签: mysql security encryption web

我正在构建一个网络应用,我想模糊客户端在浏览器中查看的主要资源,原因是安全性

以下是在网址中公开的主键(1001)的示例:https://example.com/orders/1001

如果主键以纯文本(数字)显示,则用户可以猜测我们在服务器上拥有多少资源,尝试打开其他用户的资源(所谓的FUSK攻击)以及其他可能发生的不良事件。

要对主键进行模糊处理,最安全的方法是使用与每个PK关联的加密随机字符串向DB添加列,并在客户端使用这些列而不是PK。但是,这种安全性需要付出代价:

1)由于碰撞,生成新的随机字符串可能需要多次尝试(非常罕见,但并非完全排除)。

2)删除行后,无法验证新随机密钥的唯一性(针对已删除的行),并且还可能导致与DB请求发生冲突在原始行被删除之后来。

上述问题可以通过维护一个预先填充了随机字符串的单独表来解决,但我不喜欢这种简单任务的快速堆积费用。

如何简单地使用对称密钥加密PK ?例如,Skipjack加密方法非常适合64位密钥。

问题是,这个想法有什么陷阱我不知道吗?

该想法的反对者说(不像真正的随机字符串)迟早加密可能被破坏并导致安全漏洞。看起来真的可能吗? AFAIU,对称加密被认为是非常安全的。此外,我的资源还受到用户身份验证的保护,因此PK的泄漏即使发生也不是很有害。

其他人用于主要数据库密钥混淆的是什么?加密主DB密钥是一种常见的做法吗?或者每个人都使用随机字符串映射?

1 个答案:

答案 0 :(得分:1)

加密主键并暴露加密值似乎效率低下,而且有点过分。如果您真的想沿着混淆路线走下去,也许您可​​能对hashids感兴趣。

但是,更常见的方法是使用UUID/GUID作为主键,并在URL中使用它。如果您已经在使用数字主键并且不想更改,则可以添加可以充当备用键的新GUID列 - 然后可以在此列上添加索引并公开这些值在您的网址中。

GUID以及在数据库引擎中随机生成它们的能力几乎构建在每个数据库系统中。

我还想补充一点,无法依赖网址模糊处理以确保安全 - 您必须包含正确的检查,以确保只有正确的授权用户能够访问每个ID。