在 url 中隐藏真实的数据库对象 ID
Hiding true database object ID in url's
出于安全目的，在 URL 中隐藏真实数据库对象 ID 的有用解决方案是什么？我发现解决方案之一是：
1) 使用 hashids open source project
2) 在创建对象时使用类似旧 md5 的东西生成哈希并将其存储在数据库中，然后在 url 中使用它并由它们查询，但缺点是查询自动递增的主键 (ID) 比散列更快。所以我认为 hash/unhash 的可能性会更好？
此外，由于我使用的是 Symfony，是否有我找不到的捆绑包或内置的有用功能？
请根据您的经验告诉我您认为有用的内容。
- 引自网站：
Do you have a question or comment that involves "security" and "hashids" in the same sentence? Don't use Hashids.
- 我会使用真正的加密算法，例如函数 openssl_encrypt（例如）或类似的东西。并在向外传递时加密 ID，在您的代码中使用时解密（例如数据库查询）。
而且我不建议将 ID 像任何一种加密的那样存储在基中 "garbage"，在我看来，散列您的真实 ID 非常不方便。保持内部整洁美观，仅对外显示加密。
按照您的想法，您只需要在将 URL 写入 HTML 页面之前加密您的 ID，并在处理这些 URL 时解密它们。
- 如果您只想要隐蔽的安全性，这足以满足可能 99% 喜欢在 URL 中迭代 ID 的好奇人士，您可以使用像 base64 或 rot13 这样简单的东西。当然，您也可以预先计算那些 "public IDs" 并存储在数据库中，而不是每次向最终用户显示 URL 时都进行加密。
- 如果你想要真正的安全，你必须用一些严格的非对称密码对它们进行加密，将两个密钥都存储在你身边，因为你基本上是在与自己交谈并且不想要中间人攻击。这你将无法预先计算，因为每次加密都会有不同的密文，这对这个原因有好处。
无论如何，你需要双向的东西，所以如果我是你，我会忘记这个词 "hash"，哈希的目的与你的不同。
编辑：
但是几年来每个博客都用于此任务的解决方案只是利用 URL 重写，在您的情况下将 URL 转换为 http://example.com/book/5 到 URL 就像 http://example.com/rework-by-37signals。这将彻底消除您 URL.
中任何数据库 ID 的迹象
从意识形态上讲，无论如何，您都需要能够将请求 URL 唯一映射到您的数据库内容的东西。如果您将 MySQL 数据库 ID 隐藏在任何 URL 重写层之后，您只需将这个重写的 URL 设为相同内容的新 ID。您所获得的只是防止枚举攻击和 SEF URLs.
这个问题问的人很多，选词不一（这就不好说了，"Just search for it!"）。这一事实促使博客 post 标题为 The Comprehensive Guide to URL Parameter Encryption in PHP 。
人们想在这里做什么
人们应该做什么
说明
通常，人们想要 短 random-looking URLs。这不会让您有太多空间来 encrypt then authenticate 您希望混淆的数据库记录 ID。这样做需要至少 URL 32 字节的长度（对于 HMAC-SHA256），当以 base64 编码时为 44 个字符。
一个更简单的策略是生成一个随机字符串（参见 random_compat random_bytes() 的 PHP5 实现和 random_int() 生成这些字符串）并引用该列相反。
此外，hashids are broken 通过简单的密码分析。他们的结论是：
The attack I have described is significantly better than a brute force attack, so from a cryptographic stand point the algorithm is considered to be broken, it is quite easy to recover the salt; making it possible for an attacker to run the encoding in either direction and invalidates property 2 for an ideal hash function.
不要依赖它。
出于安全目的，在 URL 中隐藏真实数据库对象 ID 的有用解决方案是什么？我发现解决方案之一是：
1) 使用 hashids open source project
2) 在创建对象时使用类似旧 md5 的东西生成哈希并将其存储在数据库中，然后在 url 中使用它并由它们查询，但缺点是查询自动递增的主键 (ID) 比散列更快。所以我认为 hash/unhash 的可能性会更好？
此外，由于我使用的是 Symfony，是否有我找不到的捆绑包或内置的有用功能？
请根据您的经验告诉我您认为有用的内容。
- 引自网站：
Do you have a question or comment that involves "security" and "hashids" in the same sentence? Don't use Hashids.
- 我会使用真正的加密算法，例如函数 openssl_encrypt（例如）或类似的东西。并在向外传递时加密 ID，在您的代码中使用时解密（例如数据库查询）。
而且我不建议将 ID 像任何一种加密的那样存储在基中 "garbage"，在我看来，散列您的真实 ID 非常不方便。保持内部整洁美观，仅对外显示加密。
按照您的想法，您只需要在将 URL 写入 HTML 页面之前加密您的 ID，并在处理这些 URL 时解密它们。
- 如果您只想要隐蔽的安全性，这足以满足可能 99% 喜欢在 URL 中迭代 ID 的好奇人士，您可以使用像 base64 或 rot13 这样简单的东西。当然，您也可以预先计算那些 "public IDs" 并存储在数据库中，而不是每次向最终用户显示 URL 时都进行加密。
- 如果你想要真正的安全，你必须用一些严格的非对称密码对它们进行加密，将两个密钥都存储在你身边，因为你基本上是在与自己交谈并且不想要中间人攻击。这你将无法预先计算，因为每次加密都会有不同的密文，这对这个原因有好处。
无论如何，你需要双向的东西，所以如果我是你，我会忘记这个词 "hash"，哈希的目的与你的不同。
编辑：
但是几年来每个博客都用于此任务的解决方案只是利用 URL 重写，在您的情况下将 URL 转换为 http://example.com/book/5 到 URL 就像 http://example.com/rework-by-37signals。这将彻底消除您 URL.
从意识形态上讲，无论如何，您都需要能够将请求 URL 唯一映射到您的数据库内容的东西。如果您将 MySQL 数据库 ID 隐藏在任何 URL 重写层之后，您只需将这个重写的 URL 设为相同内容的新 ID。您所获得的只是防止枚举攻击和 SEF URLs.
这个问题问的人很多，选词不一（这就不好说了，"Just search for it!"）。这一事实促使博客 post 标题为 The Comprehensive Guide to URL Parameter Encryption in PHP 。
人们想在这里做什么
人们应该做什么
说明
通常，人们想要 短 random-looking URLs。这不会让您有太多空间来 encrypt then authenticate 您希望混淆的数据库记录 ID。这样做需要至少 URL 32 字节的长度（对于 HMAC-SHA256），当以 base64 编码时为 44 个字符。
一个更简单的策略是生成一个随机字符串（参见 random_compat random_bytes() 的 PHP5 实现和 random_int() 生成这些字符串）并引用该列相反。
此外，hashids are broken 通过简单的密码分析。他们的结论是：
The attack I have described is significantly better than a brute force attack, so from a cryptographic stand point the algorithm is considered to be broken, it is quite easy to recover the salt; making it possible for an attacker to run the encoding in either direction and invalidates property 2 for an ideal hash function.
不要依赖它。