混淆/混淆面向公众的数据库ID真的是“最佳实践”吗？

我听说人们在互联网上到处都是演讲，这是使Web应用程序中面向公众的数据库ID晦涩难懂的最佳实践。我想它们主要是形式和网址的意思，但是我从没读过太多关于这个主题的文章。

编辑：当然，现在我问这个问题，我发现了一些有关该主题的资源：

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

这些链接满足了我的一些好奇心，但是SO帖子的选票并不多，而且在这种情况下不一定围绕该主题展开，因此我不确定该怎么做，其中一些声称第三个链接是虚假的。我将保留我的其余帖子：

我了解模糊性和安全性之间的区别，以及两者如何协同工作，但是我无法想象为什么这样做是必要的。

这有什么道理吗，仅仅是偏执狂，还是完全虚假？

我可以想到实现此目标的方法，但是当然，这会增加应用程序代码的复杂性。在什么情况下有用？如果这是一些人经常做的，它怎么通常部署？散列标识符？还有吗 似乎需要大量额外的安全性才能完成大量工作。我并不是在寻找真正的解决方案，我只是想了解人们在现实世界中将如何/为什么这样做。

这是否真的被认为是“最佳实践”，还是仅仅是微不足道的微优化？

注意：我认为有些人可能会得出错误的主意：我并不是在建议难以猜测的id是唯一的安全机制，显然会有通常的访问检查。让我们假设它们已经就位，并且仅仅知道记录的ID或哈希ID不足以授予访问权限。

我不认为这很重要，但是在某些情况下，这可能取决于您做出的其他决策。

例如，如果您要暴露顺序生成的订单ID，并且您遭到了社交工程攻击，有人打电话给客户支持并说：“嘿，我刚在新计算机上花费了2000美元，你们就向我发送了其他人的订单，一条15美元的电缆，现在我要支付2000美元”，您可以花很多时间尝试审查该问题，然后再得出结论是虚假的，或者向伪造者发送新计算机。

在主题上有相似的，不太复杂但令人尴尬的变化。如果坏人增加了订单ID，则会通过电子邮件发送指向收据的链接，并且如果未进行其他验证以确认单击该链接的人有权查看订单ID，那么您突然会无意间公开了私人客户信息给错误的人。

在这种情况下，如果数字不是连续的，则曝光会有所减轻，因为猜测不太可能产生有趣的结果。另一方面，现在您需要一种方便的方法来在客户支持交互中引用订单ID，这样在您的代表尝试区分B，PD和B时，不会导致与基于电话的客户交互的长时间来回对话。订单号BPT2015D中的T。

我想称这种混淆为“最佳实践”是很困难的，但是在某些情况下，它可以降低利用验证或授权代码中另一个弱点的难度。另一方面，是否有人知道您写了博客文章＃1或＃2559并不重要。如果ID并不是有价值的信息，即使具有额外的知识，那么对ID进行混淆也是一种最佳实践的论据就没有那么重要了。

还有第二种可能的论据，那就是您的数据库标识符可能使您与特定的数据库实现（或实例）结婚，并且当您的公司被收购或选择竞争对手时，现在您必须合并两个遗留系统或首席执行官与DynoCoreBase的代表一起喝酒，他们决定您现在将所有数据移至DynoCoreBase版本13h，并且它希望所有主键都被引导，并且您必须创建某种映射层以将旧ID转换为新ID。 ID，以使旧的URL不会损坏，但这些情况对您是否重要，在很大程度上取决于业务性质（以及客户对这些ID的参与），而不是任何常规最佳实践。

这是我的看法：

尽管“仅凭隐秘获得安全性”显然是不够的，但隐秘性甚至可以帮助安全。您必须决定，在应用程序中部署类似此类的伪装安全性是否值得付出额外的努力。

我可以想到实现安全性之外的另一个原因：

隐私

假设我们正在处理网址中的用户ID。如果Joe的用户ID为，100而Bob的用户ID为101，则很可能首先创建了Joe的帐户。尽管这在大多数应用程序中可能无关紧要，但对某些应用程序可能很重要。这是通过模糊处理来严格说明隐私的示例，因此，除非您拥有一个非常复杂的用于模糊用户ID的系统，否则很容易解决并确定ID用户3Js9kW3hTs7sa120的帐户是否长于ID用户Q8Hs73kks0hEg。

从我引用的链接：

首先是给定某个对象的URL，您可以找出围绕它创建的对象的URL。这会将数据库中的对象数量暴露给可能的竞争对手或您可能不希望拥有此信息的其他人（如盟军通过查看序列号猜测德国坦克的生产水平所证明的那样）。

公开使用自动递增的id可以公开数据库中的对象数量，并且可以公开哪些对象是首先创建的，哪些是较新的。这些信息可以消除一个事实，即企业是新的，甚至经营不善。例如：假设您订购了一本书，而您的订单ID为1。显然，您的订单是系统中的第一个订单，可能会令人不安。假设您返回并订购另一个，并且您的订单ID为9。这样就给出了两个订单之间的时间范围内仅下了7个订单的信息。这对于竞争对手可能是有价值的信息。在这种情况下，自动混淆的数字ID可能更好。

“晦涩”一词在这里可能会引起误解，并且可能导致人们认为“混淆”或“部分隐藏”。

建议您如果这些数据库记录包含任何敏感数据，则永远不要将任何内部生成的数据库密钥作为公共URL的一部分。

使用URL中的数字并访问其他记录太容易了。

我将反对主流，并告诉您，我认为使用随机的长标识符是相当不错的安全形式。

必须向有权访问该数据的任何人表明，它与密码一样敏感。当然，它的缺点是，如果它变得疯狂，它可能很难改变。

但是与通常的用户名和密码对相比，它具有两个优点。首先，用户别无选择，因此可以确保基本上无法猜测。当管理员选择其名字作为密码时，设计一个完全安全的站点毫无意义。其次，每个项目都有一个不同的标识符，因此，如果一个项目可以访问一个项目，则对另一个项目无济于事。

当然，安全层越多越好。但是，仅此方法就比两个凭据更安全。

这有两个方面：可用性和安全性。

在安全方面，模糊的ID毫无意义。重要的是，该ID绝不能成为任何非公共资源的唯一“钥匙”。这意味着，如果要授予选定用户访问某个页面的权限，仅要求URL中的页面ID是不够的，则必须实施实际的安全机制，例如用户名/密码登录或公共/专用密钥身份验证，以及适当的授权（也就是说，系统必须能够根据情况判断是否允许用户X访问资源Y并采取相应措施）。

在可用性方面，一般建议是隐藏人工密钥：它们对用户没有任何意义，并且通过以明显的方式显示它们，您会引入额外的依赖关系，因为它位于外部，因此特别难以处理软件领域-人们会写下，发送电子邮件，传真，打印，添加书签等这些ID，并且，如果您更改了这些ID，您将获得一些烦人的支持通知单。

不，您绝对肯定不希望仅知道其内部ID即可访问任意资源。这是Internet，无论您想象中存在，恶意，犯罪或纯稚的存在，实际上都存在，并且它们迟早会进入您的站点。除非您可以提供的所有服务对所有人都是完全公开的（并且即使您只有一个客户，也可以保证不会发生这种情况），否则您必须将访问权限限制在实际有权获得该服务的人员手中。

通常的解决方案是使用某种形式的授权令牌，该令牌存储在加密的会话中，并在实际将其发送出去之前检查验证是否应该对经过身份验证的用户可见。它可以是实际的安全性管理器，例如JDK附带的安全性管理器，或者可以起到相同作用的任何其他组件，只要它始终如一。（是否将内部ID公开给已经通过身份验证的人员，这也有很多利弊，这是一个有趣的问题，但是对安全性的要求较低。）

除非您受到真正意味着业务的人的攻击，否则很难计算出这样做的价值。然后，通常是停业与只是摆脱另一个挫败的脚本小子之间的区别。

显然，这取决于数据的敏感程度，但是对于中等安全性，我要做的最低限度是包括ID和校验和值。

通过在ID之前和之后添加盐（即一组随机字符的集合）并对该值进行MD5来生成校验和。

在读取ID值的每一页上，它都应生成校验和值，并将其与传递的值进行比较，如果请求不匹配，则拒绝该请求。

如果潜在的黑客能够获得足够的有效组合，则他们可能可以通过蛮力计算出Salt值，因此，如果您可以添加另一层安全保护，例如检查User ID，这也将有所帮助。