1-1用于id混淆的映射

我使用顺序ID作为主键,并且在某些情况下我不希望这些ID对用户可见,例如我可能想要避免使用类似于？invoice_id = 1234的网址,以便用户猜出系统中有多少发票作为一个整体发行.

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

必须分配额外的数据库字段.我知道我可以使用GUID作为我的主键,但我的自动增量整数PK是大多数用途的正确的东西,我不想改变它.

不得不考虑哈希/ GUID冲突的可能性.我完全同意关于GUID碰撞的所有论点,就像自发燃烧或其他任何事情一样,但是忽视特殊情况,因为它们是特殊情况与我所教过的其他事情相反,即使我知道它也会继续打扰我我应该对其他事情更加困扰.

我不知道如何安全地修剪基于散列的标识符,所以即使我的私有ID是16位或32位,我仍然坚持使用128位生成的标识符,这些标识符在url中是一种麻烦.

我对id范围的1-1映射感兴趣,可伸缩或缩小,例如16位id映射到16位id,32位id映射到32位id等,这会阻止某人尝试猜测一个时期内分配的ID总数或id分配率.

For example, if my user ids are 16 bit integers (0..65535), then an example of a transformation that somewhat obfuscates the id allocation is the function f(x) = (x mult 1001) mod 65536. The internal id sequence of 1, 2, 3 becomes the public id sequence of 1001, 2002, 3003. With a further layer of obfuscation from base conversion, for example to base 36, the sequence becomes 'rt', '1jm', '2bf'. When the system gets a request to the url ?userid=2bf, it converts from base 36 to get 3003 and it applies the inverse transformation g(x) = (x mult 1113) mod 65536 to get back to the internal id=3.

这种方案足以阻止临时用户随意观察,但很容易被一个有兴趣试图解决它的人解决.任何人都可以建议一些更强大的东西,但很容易实现PHP,没有特殊的库？这是接近自己的自己的加密方案,所以也许有一个适当的加密算法可以广泛使用并具有上面提到的可拉伸性？

编辑:退一点,一些关于编码的讨论关于从三种键中选择 - 代理(基于guid),代理(基于整数),自然.在这些方面,我试图隐藏用户的整数代理键,但我正在寻找一些可缩小的东西,使得网址不会太长,我不知道如何处理标准的128位GUID .有时,正如公主评论者在下面提出的那样,问题可以用自然键来回避.

编辑2 /摘要:

考虑到我提出的问题的限制(可拉伸性,可逆性,易于实现),到目前为止最合适的解决方案似乎是Someone和Breton建议的基于异或的混淆.

假设我可以通过默默无闻地实现混淆/安全,那将是不负责任的.知道它是一个整数序列可能是一个任何有能力的攻击者都能够利用的小儿床.

我已经考虑了额外数据库字段的想法.额外领域的一个优点是,对于试图通过查看数据库来熟悉系统的未来程序员来说,它更加直接.否则,他们必须深入挖掘源代码(或文档,ahem),以确定如何将对给定URL的请求解析为数据库中的给定记录.

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

CDR.. 7

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

在网上搜索PHP XOR加密以找到一些实现.我发现的第一个是在这里.

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

在网上搜索PHP XOR加密以找到一些实现.我发现的第一个是在这里.