用户创建时的随机 ID 号答案

【问题标题】：Random ID Number when user created用户创建时的随机 ID 号
【发布时间】：2016-10-26 08:34:50
【问题描述】：

我想使用用户的唯一 ID 来保存 cookie - 这样我就知道哪个用户登录了，然后我可以更改他们的内容以适合。

我目前只是在创建新记录时使用通常的自动 ID，但我听说创建用户帐户（特别是当您要使用该 ID 更改内容时）您不应该拥有它们1个接一个；例如不是 378、379,380 等等，更像是 138462193、109346286、982638192，所以它有点像随机唯一标识符。

我将如何实现这一目标？

这是最佳做法吗？

【问题讨论】：

这会有什么不同？它所能提供的只是一种虚假的安全感。混淆不能提供更高的安全性。如果您的应用程序允许您使用其他人的 ID 来操作事物，那么您必须修复该隐私漏洞。不要掩饰。
好的，所以使用 UUID 库
见stackoverflow.com/questions/829284/guid-vs-int-identity
只是从如果有人要尝试攻击它的角度来看（当然我有加密的密码，然后当它存储在 cookie 中时重新加密），他们将无法循环通过用户，因为他们的 id 号码之间可能存在 1 到 100000 的差距，如果您不认为这将是一个问题，那就太酷了！会让我的生活更轻松
公共 user_id 和内部 id 不必是同一件事，所以我将 auto_increment 用于内部 PK，并且（可能）使用 MAX(public_id) + RAND()*10 之类的东西作为 public_id - 但是具有适当的事务约束以防止竞争条件 - 或其他人提到的 UUID。

标签： php mysql phpmyadmin

【解决方案1】：

您保护您的数据免受 using ACL 的攻击，以限制哪些用户可以访问什么（以及使用什么数据）。用于在用户和数据之间建立所有权的外键关系，session ID regeneration 在登录时，CRSF tokens 用于防止来自其他站点的攻击，等等。
更不用说日志记录，以便能够找出问题所在什么时候出了问题。

只有在非常特殊情况下，您才需要担心用户 ID 是连续的。大多数情况下，其他用户可以通过网站本身使用此 ID。作为正常操作的一部分。
因此，向用户 ID 添加随机元素只会带来虚假的安全感。即使您保持内部 ID 与“外部”面向用户的 ID 不同，只要您使用外部 ID 来识别和更改内容，它基本上与内部 ID 相同。在大多数情况下，使用双 ID 系统的唯一正当理由是为了便于阅读。如果您不确定您的用例是否属于例外情况之一，则不是。

PS：我在您的评论中看到您说密码是加密的。希望您的意思是“加盐和散列”，更具体地说是使用password_hash ()，它是associated functions。

【讨论】：

好的，谢谢！是的，它们是加盐和散列的，服务器上的密码与加盐和散列的 cookie 版本不同。
为什么要在 cookie 中存储（散列）密码？他们永远不应该离开服务器，我想不出一个合理的情况是必要的。这是一个巨大的安全隐患！不客气，顺便说一句。很高兴我能帮上忙。 :)
我将它存储在一个 cookie 中，因此每次页面加载时，它都会通过解密存储的 cookie 密码和 uid 来检查用户是否登录，然后对数据库运行查询以查看存储的 cookie 是否为 uid并且密码与服务器中的密码匹配（从而消除了人们能够更改 cookie 数据的可能性，因为如果他们这样做，加密将不匹配，用户将被注销并且所有 cookie 信息都将被删除）
本质上，cookie中存储的密码在创建并存储在数据库中时被加盐和散列，然后在cookie中时被重新排序和散列。因此，他们将不得不破解 2 个很长的加盐和散列密码，据我所知，这将花费很长时间！并感谢您的帮助:)
这太复杂了，而且无助于提高应用程序的安全性。事实上，由于您发送的是散列密码，因此您实际上是在稍微降低安全级别。您只需要 cookie 中的会话 ID，然后将登录状态保存在会话本身中。或者，您可以对使用存储在会话中的数据或其他 cookie 进行一些验证检查。使用某种令牌值，但为此使用密码是一个很大的问题。记住：保持简单。这样一来，您和其他人就可以更轻松地保护您的代码安全。