我对内部数据库主键的公开性有疑问。
我决定使用UUIDs代替自动递增的长度（有关详细信息，请参见here）。这样，人们就无法发现我的数据的相对大小或它们随时间的增长。
现在，UUID不提供任何内部信息，但是尽管URL安全，但它不是非常友好的URL。此外，如果不应暴露长时间的PK，那么UUIDs也不应暴露。
通常，为了使UUIDs更加用户友好，人们base64对它们进行了编码。
示例：
- UUID: 7b3149e7-bdab-4895-b659-a5f5b0d0
- base64: ezFJ572rSJW2WQAApfWw0A
我的观点是：任何人仍然可以从URL中获取那些base64字符串并对其进行解码，以获得原始的UUID。这意味着即使在这种情况下，UUIDs也将最终被暴露。
我应该使用其他类型的编码吗？是否已有已知信息，或者我应该创建自定义编码？如果是，我应该遵循任何准则吗？
谢谢
答案 0 :(得分：1)
为了能够为这些标识符提供很小的保密性，乍一看，您可以使用一种哈希函数，例如SHA2（这是一种加密功能而不是编码功能）。从字面上看，这将不会给您带来任何特定的安全优势。
如果仅依赖对象引用ID进行访问控制，并尝试将其保密，那么我建议您在访问控制和授权模型中三思。 拥有随机/不可猜测/无冲突的对象参考ID是很好的，但是，如果您依靠参考ID的保密性来确保安全，则这是一个很大的缺陷（在旧OWASP Top10中，这被称为直接对象参考标识符问题，在OWASP 2017，这被称为“损坏的访问控制问题”。您需要考虑完整的AAA链：通过依赖具有短有效期的随机唯一令牌来进行访问的身份验证，授权，审计/问责制，以后可以使用该令牌来确定要绑定的系统的授权和访问级别并允许他们与他们有权使用的对象进行交互。
答案 1 :(得分：0)
不应该公开PK的原因是，它们可能（a）泄漏信息，并且（b）允许人们猜测其他值。 UUID（至少v3 / 4/5）都不是，这是首先使用它们的主要原因之一。您提到的人为因素是为什么这么多人使用base64（或其他）编码？不是为了安全。
也就是说，您绝对不要将URL保密作为安全措施； URL泄漏的方式太多了，您的用户甚至可能有意这样做-但是如果向其朋友发送链接意味着该朋友可以完全访问其帐户，他们会感到非常沮丧。