language-agnostic - id 混淆的 1-1 映射

Question

我使用顺序 id 作为主键，有些情况下我不希望这些 id 对用户可见，例如我可能想避免像 ?invoice_id=1234 这样的 url 允许用户猜测系统有多少发票整体是发行。

我可以添加一个带有 GUID 的数据库字段，或者从哈希函数、随机字符串和/或数字基转换中产生的一些东西，但是这种方案有三个我觉得很烦人的问题:

必须分配额外的数据库字段。我知道我可以使用 GUID 作为我的主键，但我的自动递增整数 PK 对大多数用途来说都是正确的，我不想改变它。

必须考虑散列/GUID 冲突的可能性。我完全同意关于 GUID 碰撞与自燃或其他任何事情一样可能发生的所有论点，但无视特殊情况，因为它们是特殊的，与我所学的其他一切背道而驰，即使我知道，它仍然困扰着我我应该更关心其他事情。

我不知道如何安全地修剪基于哈希的标识符，所以即使我的私有(private) id 是 16 位或 32 位，我也会坚持使用 128 位生成的标识符，这些标识符在 url 中很麻烦。

我对可伸缩或可收缩的 id 范围的 1-1 映射感兴趣，例如，16 位 id 映射到 16 位 id，32 位 id 映射到 32 位 id，等等，这会阻止有人尝试猜测分配的 id 总数或一段时间内的 id 分配率。

例如，如果我的用户 ID 是 16 位整数 (0..65535)，那么会混淆 id 分配的一个转换示例是函数 f(x) = (x mult 1001) mod 65536。内部 id 序列1, 2, 3 成为 1001, 2002, 3003 的公共(public) id 序列。从基数转换的进一步混淆层，例如到基数 36，序列变为 'rt', '1jm', '2bf'。当系统收到对 url ?userid=2bf 的请求时，它从基数 36 转换为 3003，并应用逆变换 g(x) = (x mult 1113) mod 65536 以返回内部 id=3。

这样的方案足以阻止临时用户的随意观察，但它很容易被有足够兴趣试图解开谜题的人解决。任何人都可以提出一些更强大的东西，但在没有特殊库的情况下很容易在 PHP 中实现吗？这已经接近于自己动手的加密方案，所以也许有一种适当的加密算法可以广泛使用并具有上述可伸缩性属性？

编辑:退后一点，在 codinghorror 进行一些讨论关于从三种键中进行选择 - surrogate (guid-based), surrogate (integer-based), natural。在这些方面，我试图向用户隐藏一个整数代理键，但我正在寻找一些可缩小的东西，使网址不会太长，我不知道如何处理标准的 128 位 GUID .有时，正如评论者公主在下面建议的那样，这个问题可以通过一个自然键来回避。

编辑 2/总结:

鉴于我提出的问题的限制(可伸缩性、可逆性、易于实现)，到目前为止最合适的解决方案似乎是有人和布列塔尼建议的基于异或的混淆。

假设我可以通过默默无闻实现混淆/安全之外的任何事情，这是不负责任的。它是一个整数序列的知识可能是任何有能力的攻击者都能够利用的 Gradle 。

我对额外数据库字段的想法进行了更多思考。额外字段的一个优点是，它让 future 的程序员更容易通过查看数据库来熟悉系统。否则，他们将不得不深入研究源代码(或文档，啊哈)来弄清楚对给定 url 的请求如何解析为数据库中的给定记录。

如果我允许额外的数据库字段，那么问题中的其他一些假设就变得无关紧要(例如，转换不需要是可逆的)。那变成了一个不同的问题，所以我将把它留在那里。

Answer 1

我发现简单的 XOR 加密最适合 URL 混淆。您可以继续使用您正在使用的任何序列号而无需更改。进一步的 XOR 加密不会增加源字符串的长度。如果您的文本是 22 字节，则加密字符串也是 22 字节。不像 rot 13 那样容易被猜测，但不像 DSE/RSA 那样重量级。

在网络上搜索 PHP XOR 加密以找到一些实现。我找到的第一个是 here .