[B-12][medium] 认证没有超时与并发上限：argon2 排队无界、并发尝试可绕过锁定、PHC 参数写死 #19

New Issue

2026-09-30T13:56:54+08:00

nixevol commented

2026-09-30 13:56:54 +08:00

编号：B-12　严重级：medium　工作线：broker（internal/broker） + 身份、群、在线与认证基础（internal/app/identity、group、presence、internal/auth）　来源：审查 I-11
依赖：无　被依赖：无

结论与统一方案

采用审查 I-11 的方案，并吸收审查 P-22 第三点：

OnConnect 的认证用 30 秒超时的 ctx，超时按内部故障处理（不回 CONNACK，客户端按网络故障重连）；校验通过后若 cl.Closed() 已断开就不轮换令牌。
按编号限制同时进行的密码校验（1–2 个），或在 Check 时预占一个失败名额；哈希池设排队上限，超出按服务器忙处理。
校验时解析并使用哈希里保存的参数（设上限），参数过旧时在校验成功后异步重新哈希（DEVELOPMENT 12）。

改动文件

internal/broker/hooks.go、authn.go；internal/auth/pool.go、phc.go。

与其他问题的交互 / 冲突说明

internal/auth/locks.go 由 U-03、U-04 修改，本条不碰。
hooks.go 的 OnConnect 与 B-01、B-05 相邻，按 broker 线顺序合入。

验收与测试

池大小 1、注入慢校验：超时后连接关闭，令牌没有被轮换。
并发 50 次错误密码：实际校验次数接近阈值。
旧参数的哈希能登录，并被重新哈希。

问题明细（各区审查原文，证据含文件与行号）

以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。解决方案以本 issue 上方的"结论与统一方案"为准；原文里的方案与之不一致时，按上方执行。

[I-11] argon2 池排队无上限、MQTT 登录无超时；并发尝试能绕过锁定；PHC 参数写死

严重级：medium
分类：安全 / 设计
现象与影响
- (a) OnConnect 用 context.Background() 做认证，排队中的校验永远不会取消。SDK 30 秒后已经放弃重连，服务器还在为它算 argon2，校验成功后甚至会轮换令牌。认证中的连接数不受任何限制。
- (b) 锁定流程是「先 Check，校验完再 Fail」。在第一个 Fail 记录之前，并发的尝试会全部通过 Check。同一编号加 IP 并发 1000 次，就真的要算 1000 次 argon2。
- (c) decodePHC 要求 m/t/p 必须等于当前常量。以后一旦调高参数，所有旧哈希都会被当作内部故障，客户端无限重连。DEVELOPMENT 12 要求参数随哈希一起存，校验成功后重新哈希。
证据：broker/hooks.go:70；auth/pool.go:59-75；broker/authn.go:198-215；auth/phc.go:61-90。
文档依据：DEVELOPMENT 12（1145-1146）；第 5 节（295）「锁定期内直接拒绝，不做哈希计算」。
为何不是故意设计：没有偏差记录。
解决方案
1. 认证加 30 秒超时，超时按内部故障处理；校验通过后先检查 cl.Closed()，已断开就不轮换令牌。
2. 按编号限制同时进行的密码校验数（1–2 个），或在 Check 时预占一个失败名额；池设排队上限，超出按服务器忙处理。
3. 校验时解析并使用哈希里的参数（设上限），参数过旧时在校验成功后异步重新哈希。
改动文件：broker/hooks.go、broker/authn.go、auth/pool.go、auth/phc.go。
与其他模块的交互/冲突风险：超时和「忙」都走「服务器暂时不可用」的语义，符合 F02 的分类。
需补测试
- 池大小 1、注入慢校验：超时后连接关闭，令牌没有被轮换。
- 并发 50 次错误密码：实际校验次数接近阈值。
- 旧参数的哈希能登录，并被重新哈希。
置信度：代码阅读确定。

_{复审基线：main 4059a15（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。}

**编号**：B-12　**严重级**：medium　**工作线**：broker（internal/broker） + 身份、群、在线与认证基础（internal/app/identity、group、presence、internal/auth）　**来源**：审查 I-11 **依赖**：无　**被依赖**：无 ### 结论与统一方案采用审查 I-11 的方案，并吸收审查 P-22 第三点： 1. `OnConnect` 的认证用 30 秒超时的 ctx，超时按内部故障处理（不回 CONNACK，客户端按网络故障重连）；校验通过后若 `cl.Closed()` 已断开就不轮换令牌。 2. 按编号限制同时进行的密码校验（1–2 个），或在 Check 时预占一个失败名额；哈希池设排队上限，超出按服务器忙处理。 3. 校验时解析并使用哈希里保存的参数（设上限），参数过旧时在校验成功后异步重新哈希（DEVELOPMENT 12）。 ### 改动文件 `internal/broker/hooks.go`、`authn.go`；`internal/auth/pool.go`、`phc.go`。 ### 与其他问题的交互 / 冲突说明 - `internal/auth/locks.go` 由 U-03、U-04 修改，本条不碰。 - hooks.go 的 `OnConnect` 与 B-01、B-05 相邻，按 broker 线顺序合入。 ### 验收与测试 - 池大小 1、注入慢校验：超时后连接关闭，令牌没有被轮换。 - 并发 50 次错误密码：实际校验次数接近阈值。 - 旧参数的哈希能登录，并被重新哈希。 --- ### 问题明细（各区审查原文，证据含文件与行号） > 以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。**解决方案以本 issue 上方的"结论与统一方案"为准**；原文里的方案与之不一致时，按上方执行。 #### [I-11] argon2 池排队无上限、MQTT 登录无超时；并发尝试能绕过锁定；PHC 参数写死 - **严重级**：medium - **分类**：安全 / 设计 - **现象与影响** - (a) OnConnect 用 `context.Background()` 做认证，排队中的校验永远不会取消。SDK 30 秒后已经放弃重连，服务器还在为它算 argon2，校验成功后甚至会轮换令牌。认证中的连接数不受任何限制。 - (b) 锁定流程是「先 Check，校验完再 Fail」。在第一个 Fail 记录之前，并发的尝试会全部通过 Check。同一编号加 IP 并发 1000 次，就真的要算 1000 次 argon2。 - (c) `decodePHC` 要求 m/t/p 必须等于当前常量。以后一旦调高参数，所有旧哈希都会被当作内部故障，客户端无限重连。DEVELOPMENT 12 要求参数随哈希一起存，校验成功后重新哈希。 - **证据**：`broker/hooks.go:70`；`auth/pool.go:59-75`；`broker/authn.go:198-215`；`auth/phc.go:61-90`。 - **文档依据**：DEVELOPMENT 12（1145-1146）；第 5 节（295）「锁定期内直接拒绝，不做哈希计算」。 - **为何不是故意设计**：没有偏差记录。 - **解决方案** 1. 认证加 30 秒超时，超时按内部故障处理；校验通过后先检查 `cl.Closed()`，已断开就不轮换令牌。 2. 按编号限制同时进行的密码校验数（1–2 个），或在 Check 时预占一个失败名额；池设排队上限，超出按服务器忙处理。 3. 校验时解析并使用哈希里的参数（设上限），参数过旧时在校验成功后异步重新哈希。 - **改动文件**：`broker/hooks.go`、`broker/authn.go`、`auth/pool.go`、`auth/phc.go`。 - **与其他模块的交互/冲突风险**：超时和「忙」都走「服务器暂时不可用」的语义，符合 F02 的分类。 - **需补测试** - 池大小 1、注入慢校验：超时后连接关闭，令牌没有被轮换。 - 并发 50 次错误密码：实际校验次数接近阈值。 - 旧参数的哈希能登录，并被重新哈希。 - **置信度**：代码阅读确定。 --- <sub>复审基线：main `4059a15`（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。</sub>