开发者工具 · UUID 生成器
随机 UUID 作为密码重置或会话令牌是否安全？
· 为什么它很重要
uuid 密码学 浏览器 API
来自 CSPRNG 的 v4 UUID 具有大量熵，那么为什么安全审查者仍然对 UUID 令牌皱眉呢？这篇文章将熵问题与设计问题分开。
使用行的 UUID 的重置链接 - 一个常见的快捷方式以及它可能不安全的两个截然不同的原因
常见快捷方式：使用用户的 UUID 行标识符作为密码重置令牌。该表有一个 uuid 列；它是独一无二的；很难猜测（如果是 v4）。 URL 为 /reset? 令牌=550e8400-e29b-41d4-a716-446655440000。安全审查员立即拒绝它，不是因为 UUID 很弱，而是因为它结合了两个应该独立的问题。行 UUID 是稳定的并且通常是公开可见的（在 URL、API、日志中）。重置令牌应该是一次性且保密的。重复使用 UUID 行作为令牌意味着用户的身份及其重置凭证具有相同的值，并且凭证将永远存在而不是过期。知道用户 ID 的攻击者可以执行重置。五年前复制粘贴重置链接的用户仍然可以使用它。这些是设计缺陷，而不是熵缺陷。
熵检查：122 随机位 - 为什么 CSPRNG 生成的 v4 无法通过暴力破解
随机性检查是必要的，但还不够。版本 4 保留四个版本位和两个变体位，当实现随机填充其他字段时，留下 128 - 4 - 2 = 122 随机位置。该推导没有提及过期、存储或授权。生成器检查询问这些字段是否来自 CSPRNG 而不是 Math.random 或时间戳。 ToolAcre 满足该生成器边界。设计检查仍然是特定于应用程序的：重置凭证需要单独的生命周期、单向存储表示、成功使用后失效以及从服务风险策略中选择的到期时间。即使安全地生成了用户的永久记录 ID，重复使用该 ID 也无法实现分离。
生成器检查：UUID 令牌实际上失败的地方 — 基于 Math.random 的生成、v1 时间戳和 MAC 地址以及可预测的种子
一个可行的示例：密码重置方案失败，然后通过三项检查。熵检查失败：服务器通过 Math.random() 发出重置令牌，打包为 v4 UUID。攻击者观察三个令牌并预测第四个。生成器检查失败：服务器使用 v1 UUID 作为重置令牌，包括值中的创建时间戳和 MAC 地址。攻击者读取时间戳，了解何时发出重置，并缩小搜索窗口。通过熵检查，但未通过设计检查：服务器使用 crypto.getRandomValues 中的 v4 UUID，但将其以纯文本形式存储在数据库中，并且不设置过期时间。破坏数据库的攻击者会读取重置令牌，并在几周后使用它们重置帐户。三项检查是独立的；你必须通过全部三项。
设计检查：标识符与凭证 — 为什么重用记录的主键作为秘密结合了两个应该独立轮换的东西
通过熵和生成器检查但未通过设计检查（无哈希、无到期、无每次使用失效）的重置令牌方案仍然容易受到攻击。处理令牌服务器端：当用户请求重置密码时，从 crypto.getRandomValues 生成新的随机令牌（不是行 UUID）。存储单向表示而不是呈现值，设置特定于策略的到期时间，并在成功使用后使记录无效。当用户单击链接时，通过电子邮件查找用户，获取存储的哈希值，将提供的令牌与哈希值进行比较，检查过期情况，并仅在令牌有效且尚未过期时执行重置。立即使令牌失效（将其删除或将其标记为已使用），使其无法重复使用。切勿记录原始令牌；仅记录用户 ID 和操作。
处理令牌服务器端 — 存储哈希值、设置到期日、使用时无效，并且从不记录原始值
令牌不应出现在错误消息或数据库中，除非经过哈希处理。完整的身份验证设计超出了 UUID 文章的范围，但原则仍然成立：122 位随机令牌本质上并不是访问令牌。随机性是比较容易的部分； ToolAcre 生成器为您提供 CSPRNG 支持的 UUID。困难的部分是设计：存储前进行散列、设置过期时间、使用时失效、防止将永久 ID 重复用作临时机密、审核谁访问了什么以及何时访问。仅根据令牌的熵批准重置链接方案的安全审查员将跳过其余的分析。如果开发人员认为 CSPRNG 支持的 UUID 足以用于密码重置链接，而无需散列、过期和失效，那么他低估了威胁。随机性可以防止猜测；该设计可以防止重放、过期和误用。
工作示例 - 针对每次检查检查重置链接方案并重写薄弱部分
ToolAcre 生成器正确处理了随机性部分；应用程序必须正确完成设计部分。针对所有三项检查测试您自己的重置链接代码：它是否使用 CSPRNG（crypto.getRandomValues、crypto.randomUUID 或加密库），而不是 Math.random？令牌有有效期吗？令牌在存储之前是否经过哈希处理？ token使用后会失效吗？代码是否避免重复使用用户的永久 ID 作为临时令牌？如果您对所有这些问题的回答都是肯定的，那么您的重置链接设计就是合理的。 ToolAcre生成器是CSPRNG部分；其余的是您必须仔细检查的应用程序代码。了解三个安全层有助于您审核第三方 UUID 库和框架。当您评估库时，请检查它是否使用 CSPRNG（熵检查），而不是弱随机源。检查它是否记录了它使用的来源以及原因（生成器检查）。
这不包括什么——完整的身份验证设计、MFA 和速率限制，这些与令牌熵一样重要
检查示例代码和文档是否强调设计原则：散列、过期、失效（设计检查）。通过所有三项检查的图书馆很少见。大多数人只关注熵。 ToolAcre 生成器使用 crypto.getRandomValues 通过熵和生成器检查。设计检查是您的责任；图书馆无法知道您的过期要求或哈希策略。调试损坏的复位链路系统通常会发现三种故障之一。如果用户报告收到不再有效的重置链接，则可能的问题是过期：令牌已颁发，但在用户单击链接之前已过期。如果令牌被多次重复使用，失效就会被打破。如果令牌出现在错误消息或调试输出中，则日志记录会泄漏它们。如果重置链接对一个用户有效，但对另一个用户无效，则可能存在数据库复制滞后或过期计算时区问题。如果合法的重置请求随机失败，CSPRNG 可能会损坏（罕见）。
要点：随机性是最简单的部分 - ToolAcre 生成器为您提供 CSPRNG 支持的 UUID；剩下的就是设计纪律
从日志记录开始：启用详细的审核日志以进行重置链接生成和验证，然后重现问题并跟踪流程。 ToolAcre 生成器确保前两项检查通过；解决重置链接问题几乎总是属于设计类别。生产重置链接系统的最佳实践包括：为每个重置请求生成新的随机令牌，而不是重复使用旧令牌。将单向表示与帐户和创建元数据一起存储，然后从服务记录的风险策略中选择到期时间。验证成功后立即使token失效。记录重置请求和成功以供审核。实施速率限制以防止暴力攻击。仅通过电子邮件发送重置链接，而不是短信或未加密的渠道。通知用户密码重置尝试（以便他们可以检测到未经授权的重置）。 ToolAcre 生成器为您提供随机性；遵循这些做法可以给您带来安全感。