7. Security Considerations (安全考虑)

7.1 Entropy of the code_verifier (code_verifier 的熵)

安全模型依赖于攻击者无法学习或猜测代码验证器这一事实. 遵守这一原则至关重要. 因此, 必须以加密随机的方式创建代码验证器, 并具有足够高的熵, 使得攻击者猜测它变得不切实际.

客户端应该 (SHOULD) 创建一个具有至少 256 位熵的 "code_verifier". 这可以通过让合适的随机数生成器创建一个 32 个八位字节的序列来完成. 然后可以对该八位字节序列进行 base64url 编码, 以生成一个 43 个八位字节的 URL 安全字符串, 用作具有所需熵的 "code_challenge".

7.2 Protection against Eavesdroppers (防止窃听者)

客户端禁止 (MUST NOT) 在尝试 "S256" 方法后降级到 "plain". 支持 PKCE 的服务器必须 (REQUIRED) 支持 "S256", 而不支持 PKCE 的服务器将简单地忽略未知的 "code_verifier". 因此, 当提供 "S256" 时出现错误只能意味着服务器有故障或 MITM 攻击者正在尝试降级攻击.

"S256" 方法可以防止窃听者观察或拦截 "code_challenge", 因为如果没有验证器, 就无法使用挑战. 使用 "plain" 方法时, 攻击者有可能在设备上或在 HTTP 请求中观察到 "code_challenge". 由于在这种情况下代码挑战与代码验证器相同, 因此 "plain" 方法无法防止对初始请求的窃听.

使用 "S256" 可以防止 "code_verifier" 值被攻击者披露.

因此, 不应该 (SHOULD NOT) 使用 "plain", 它仅用于与已部署的实现的兼容性, 其中请求路径已受到保护. 除非由于某些技术原因无法支持 "S256", 否则不应该 (SHOULD NOT) 在新实现中使用 "plain" 方法.

应该 (SHOULD) 使用 "S256" 代码挑战方法或其他加密安全的代码挑战方法扩展. "plain" 代码挑战方法依赖于操作系统和传输安全性不向攻击者披露请求.

如果代码挑战方法是 "plain", 并且代码挑战要在授权 "code" 内部返回以实现无状态服务器, 则必须 (MUST) 以只有服务器才能解密和提取它的方式对其进行加密.

7.3 Salting the code_challenge (为 code_challenge 加盐)

为了降低实现复杂性, 在生成代码挑战时不使用加盐, 因为代码验证器包含足够的熵来防止暴力攻击. 将公开已知的值连接到代码验证器 (包含 256 位熵), 然后使用 SHA256 对其进行哈希以生成代码挑战, 不会增加暴力破解有效 code_verifier 值所需的尝试次数.

虽然 "S256" 转换类似于哈希密码, 但存在重要差异. 密码往往是相对低熵的单词, 可以离线哈希并在字典中查找哈希值. 通过在哈希之前将唯一但公开的值连接到每个密码, 攻击者需要搜索的字典空间将大大扩展.

现代图形处理器现在允许攻击者实时计算哈希值, 速度比从磁盘查找更快. 这消除了加盐在增加暴力攻击复杂性方面的价值, 即使对于低熵密码也是如此.

7.4 OAuth Security Considerations (OAuth 安全考虑)

[RFC6819] 中提出的所有 OAuth 安全分析都适用, 因此读者应该 (SHOULD) 仔细遵循.

7.5 TLS Security Considerations (TLS 安全考虑)

当前的安全考虑可以在 "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [BCP195] 中找到. 这取代了 OAuth 2.0 [RFC6749] 中的 TLS 版本建议.