Google Authenticator 用的是 TOTP 算法,每30秒基于密钥和UTC时间戳生成一个动态验证码。密钥得用totp.Generate生成标准Base32字符串,验证时得先解码成字节切片,再用time.Now().UTC().Unix()当时间戳。这几个步骤,哪一步错了,验证就过不了。

Golang怎么实现TOTP两步验证_Golang如何用pquerna/otp生成和验证动态口令【实战】

直接用 github.com/pquerna/otp/totp 库,别自己手算 HMAC 或拼 Base32。90% 的“扫码后验证失败”问题,都出在这两步上。

密钥生成必须用 totp.Generate,不能手搓随机字符串

密钥生成这步,必须用 totp.Generate,别自己手搓随机字符串。为什么?Google Authenticator 和 Authy 只认 RFC 4648 标准 Base32 编码的密钥,而且原始密钥字节长度至少 10 字节、熵值足够高。自己用 crypto/rand.Readbase32.StdEncoding.EncodeToString 拼,容易因为字节长度不对、编码表误用(比如用了 URLEncoding)、大小写或填充符处理错,导致扫码失败。

验证时必须先 base32.StdEncoding.DecodeString 密钥字符串

验证时犯的错,往往更隐蔽。数据库里存的是 Base32 字符串(比如 "JBSWY3DPEHPK3PXP"),但 totp.ValidateTime 第二个参数要的是原始字节切片([]byte)。跳过解码直接传字符串,HMAC 计算对象就错了,永远不匹配。

时间戳必须是 time.Now().UTC().Unix(),不是纳秒、毫秒或本地时区

时间戳这块,也是个容易踩的坑。 totp.ValidateTime 的第三个参数要求是 int64 类型的 Unix 秒级时间戳(从 1970-01-01 UTC 开始计数)。传错类型或时区,会导致时间步长计算偏移,所有验证全挂。

启用 MFA 前必须校验用户输入的首次 TOTP 值

最后,绑定流程也需要注意。用户扫码后,前端会提交一个当前动态码。这一步不是形式主义,它是唯一能确认“密钥已正确导入客户端+时间基本对齐”的手段。跳过它直接存密钥,等于允许攻击者上传任意 Base32 字符串完成绑定。

说到底,最容易被忽略的就是密钥解码和时间戳类型这两个操作。看起来简单,但错一个字符或一个方法名,整个 TOTP 就静默失效,而且没有任何明确报错提示——它只会安静地返回 false。这才是关键所在。

本文转载于:https://www.php.cn/faq/2322203.html 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。