我计划实现我自己的非常简单的“哈希”公式，为具有多个用户的应用程序添加一层安全性。我目前的计划如下：
- 用户创建一个帐户，此时后端会生成一个 ID。 ID 通过公式运行（假设 ID * 57 + 8926 - 36 * 7，或同样随机的东西）。然后，我将新的用户 ID 和新的“哈希”数字发送回前端，并将它们存储在
localStorage.
- 用户尝试访问安全区域（假设是设置页面，以便他们可以更改自己的设置）。
- 我向后端发送两个值：它们的 ID 和哈希值。我通过相同的公式运行 ID，以检查它是否与我收到的哈希值匹配。如果检查通过，他们就可以进入。所以，如果有人尝试过，比如说，更改他们的 ID
localStorage要访问其他用户的设置页面，他们实现这一目标的唯一方法就是猜测公式是什么。他们可以很容易地猜到用户 ID，但猜到对应的数字是 ID * 57 + 8926 - 36 * 7 的结果似乎不太可能。
我这样做是因为它比数据库查找实际哈希值更快/更便宜......我认为？使用包来创建某种主键/uuid 而不是“散列”我自己的值并每次进行数据库查找是否更有意义？
技术堆栈：FE 上的 React、BE 上的 Python、SQL 数据库。
我看到很多帖子都说“不要自己动手”——这是绝对的吗？
是的。原因是，每当非密码学家尝试开发自己的算法时，他们总是会陷入许多坑，从而使算法的安全性几乎毫无用处。
例如，给定两个连续的 ID 和“哈希”对，您的特定方案可能会被轻易破坏。 （这是一个简单的算术数列，给定两个连续值推导算术数列的公式是六年级左右的数学。）
我这样做是因为它比数据库查找实际的散列值更快/更便宜......
性能差异可能可以忽略不计。别担心。
如果信息不是特别敏感，只需为每个用户分配一个随机生成的 128 位数字即可。有人猜测有效用户号码的机会几乎为零。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
