【发布时间】：2013-01-15 13:02:58
【问题描述】：
我们目前有一个用户登录的网站。
我们有一个带有 userId 的用户表。
我们现在希望用户有一个重复的个人资料，这与他们的主要个人资料完全分开。这需要是一个秘密的个人资料。
现在我们可以只将两条记录添加到数据库中，但 ID 将是连续的（直到我们达到很高的注册命中率），因此用户可以锻炼 userId 将与更高的一个 ID 相关。
我意识到这不是一个理想的解决方案，但它是一个大型软件项目的后期更改，因此我们试图尽可能务实，同时尽可能少更改代码。
选项：
- 关闭自动递增 ID，并构建我们自己的 keyGeneration 表。从 0 开始一张表，从 1000000000 开始一张秘密表。然后我们可以关闭用户表中的自动递增 ID，并使用这些密钥。
问题是，运行键 1,1000000000,2,1000000001,3,1000000002 会导致大量索引问题吗？我们是否必须一直强制重建索引？
- 我们只为第二个配置文件 ID 键入一个单独的表，再次从 10000000000 开始。然后我们修改所有代码以检查 id > 999999999 并翻转服务器端的逻辑，以便查找正常工作。
意味着在用户 ID 从前端传递到站点的任何地方进行检查。
由于我们没有做太多，（我们显然主要是安全地获取登录用户的 userId，它可能没那么糟糕。
无论如何，只是想知道是否有人对此有任何想法？
///////编辑
为了进一步说明这一点，想象一下在 stackoverflow 或 facebook 上，您有 2 个可以控制的配置文件，它们之间没有链接。就像 Facebook 上的多个用户都可以充当主页帐户一样，但没有从该帐户返回到真实用户个人资料的链接。
基本上为了不破坏参照完整性或重新编写太多代码，我真的想将一个 ID (int) 传递回这些帐户的前端。然后整个系统就像它所做的那样继续滴答作响。
Guid 可能很酷！但这会产生性能开销（不是我真正关心的；），但这也意味着编写大量代码来处理传递给前端的 Guids（不是我们依赖前端变量是正确的）但这就是为什么我建议上面的高 int 解决方案。由于我们仍然在后台潜伏着 ASP.NET 成员资格，我几乎认为这可能会很好，但是 A）我们计划有一天删除那个（或迁移到简单的成员资格）b）我们在用户表中使用顺序 Guid 生成来提高性能（再次抱歉在需要之前谈论优化）
【问题讨论】：
-
将
isSecret字段添加到表中，并且不允许用户查看隐藏的个人资料。 -
您可以创建一个没有自动 inc id 的新 User2 表。然后从 User1 使用插入触发器创建初始重复记录。
-
知道id很危险的原因是什么？如果安全性仅依赖于不知道 ID，那听起来……不完整。了解上下文对于安全相关问题很重要。
-
同意@MarcGravell - 从理论上讲，您仍然应该在数据或代码中以某种方式在两个用户帐户之间建立链接 - 这里的问题不是密钥的值，而是整体安全模型。我看到将其拆分到另一个表的唯一原因可能是某种表级别的安全性 - 但这也可以在一个带有标志的表中完成，正如 Minras 建议的那样......
-
为了更深入地了解这一点，想象一下在 stackoverflow 或 facebook 上，您有 2 个可以控制的配置文件，它们之间没有链接。就像 Facebook 上的多个用户都可以充当一个主页帐户一样，但没有从该帐户返回到真实用户个人资料的链接。如果 int 之间存在链接，甚至有机会，那么我们就有安全风险（任何普通字体最终用户都不应该能够锻炼哪个帐户链接到哪个帐户）好吧，所以不使用 int 是个好主意，但是这意味着大量的代码更改。
标签： c# java mysql sql sql-server