【发布时间】：2012-11-26 23:45:34
【问题描述】：
我总是在我的数据库中包含一个具有自动增量功能的列 ID。有什么理由我不想将其用作社交网站的用户 ID。该 ID 将为公众所知并在 URL 中使用，等等。认为这比添加另一个功能来为成员创建单独的唯一 ID 更容易。只是想看看其他人在我的代码中使用它之前是否发现了任何问题。
【问题讨论】：
【发布时间】：2012-11-26 23:45:34
【问题描述】：
ID 本身会泄露信息，使第三方能够估计他或她在您的网站上注册的日期。因此，如果 Alice 是 Bob 的朋友，并且知道她去年注册并且他在 3 天后关注并且她的 id 是 100，而他的 id 是 150，她就会知道 Carol，她不是她的朋友，当时在您的网站上注册了，并且不是 Carol 声称的“最近”，而是试图在您的社交媒体网站上为她与 Alice 不是“朋友”寻找借口！
这是个问题吗？您将自己决定，但就我个人而言，我更愿意有点专业/偏执（这两个经常在一起，无论这对我们的职业意味着什么！）并避免在 URL 中包含自动增量 ID，即使是最轻微的安全性/隐私问题。或者至少，建议你成为:-)
如果您决定走 Virtue 的道路，您可能需要考虑其他 id 也会泄露信息（例如，如果 Alice 发现她的个人资料 id 比 Bob 的数字小，她会比她声称的更早认识 Carol） .因此，虽然您似乎可以添加一个 GUID 列，并将其用作辅助 id，可以安全地包含在 URL 中，但最好从自动增量 id 切换到使用 GUID。 （更多关于 GUID 的信息：http://en.wikipedia.org/wiki/Globally_unique_identifier）
希望有所帮助:-)
【讨论】：
-
我真的很喜欢你的故事。它让我想起了当年的数学问题。但你的推理足够公平。感谢您的帮助
-
这在技术上绝对是一个有效的观点。虽然我不认为它是一个炫耀的东西（在社交网站上，“成员自”日期很可能无论如何都会出现），但仍应提及。
-
@kdjernigan：谢谢！我很高兴你喜欢这个故事。我也很高兴想出它:-)
我也认为，这是解决基本问题的规范方法。
它还使链接到具有其他用户 ID 的其他站点变得微不足道：只需有一个带有用户 ID 的表（如您所描述的）、其他站点 ID（来自 foreign sites 表）、用户 ID 在那里使用。
我观察到的唯一缺点是，当一些脚本小子使用 n、n+1、n+2... 来测试具有易受攻击密码的用户 ID 时。虽然随机 ID 使这变得更加困难，但我个人认为，这应该在其他地方处理。
【讨论】：
-
我对你说的话感到困惑。使用其他用户 ID 链接到其他网站是什么意思？我理解 n, n+1, n+2 的例子，但你的意思是它应该在其他地方处理吗？在我的剧本中？如果是这种情况，您会推荐什么？
-
关于其他网站：您正在谈论一个社交网站 - 这很可能在未来您希望将您的用户与他们在 other 社交网站上的身份相关联网络。我认为这应该很早就设计好了，因此我的方法。
-
关于 n, n+1, ... 情况：AUTO_INCREMENT 用户 ID 的一个缺点是，您可以从一个已知用户 ID 轻松找出其他可能有效的用户 ID - 比带有随机 ID。但我认为，这不应该与编号方案相抵触。监控蛮力尝试应该与恕我直言完全分开
-
我们的登录系统将基于电子邮件地址，我们计划添加一个系统，该系统将在多次尝试失败后临时阻止电子邮件地址，并在多次尝试失败后临时阻止 IP。是不是和你说的一样？
-
没错。这就是我所说的“必须在其他地方处理”。不过要小心阻止 IP - 在一个充满 NAT 的世界中，甚至剩下一个或另一个代理龙，这可能会受到伤害 - 至少在这里（在 AT）所有移动流量都通过 NAT。
我认为这是一种完全有效的方法。如果您想支持用户的唯一 ID（例如，如果他们想要唯一的 user_id），您可以稍后将其作为单独的列添加到用户表中。
【讨论】：
-
现在您是否将唯一 ID 称为用户名之类的东西？还是什么？
不，您没有理由不想将其用作 user_id。
如果您将其他列设置为 id，您将遇到以下问题：
- 如何生成用户id
- 如何检查表中是否有重复的id
此外，如果您通过主键（也是 AUTO_INCREMENT）执行 SELECT 过滤，则在表中查找特定用户会更快。
【讨论】：