Algorithm HOTP-计数器值安全性

我有两个关于安全问题的“（H）OTP算法”的问题

我们都知道“TOTP”是如何工作的，我们扫描一个二维码，每30秒就会显示一个新的6-8位数的代码，几乎没有什么神奇之处

现在回到“HOTP”，除了来自“TOTP”的有效载荷外，我们还得到一个“counter”值

在客户端显示计数器值是否安全？还是会导致安全问题

还有一个普遍的问题：“秘密”值总是16位吗？（我这样问是因为我看到mfa应用程序接受的数字少于16位）

---

谢谢

第一个问题：在客户端显示计数器值安全吗

“柜台”不是秘密。虽然“密钥”仍然是秘密的，但知道当前或最近的“计数器”值对对手来说是没有用的。如果“密钥”被泄露，那么你就有麻烦了。RFC4226说了很多关于保守“秘密密钥”的秘密，而对保守“计数器”的秘密却一无所知。（而TOTP显然不是这样！）

如果一个对手确实学会了“秘钥”和“计数器”，那么他们就处于劣势。如果他们不得不猜测，并且8字节的“计数器”是随机种子，那么这看起来就像是蛮力攻击。RFC第7.1节给出了认证协议P的要求，包括：

RP2-p不应该容易受到暴力攻击。这意味着建议在验证服务器端使用节流/锁定方案

因此，安全地保存“计数器”有一些额外的安全性，但是客户端和服务器都不需要这样做。即使客户机这样做了，服务器也可能不这样做。这不是正式安全分析的一部分

“E.4.基于计数器的重新同步方法”（RFC）要求客户端发送其“计数器”，我们有：

RP3-p应该通过安全通道实现，以保护用户的隐私并避免重播攻击

…未提及安全发送“计数器”，除非有副作用

因此，对第一个问题的简短回答是“是”，“是的，在客户端显示计数器值是安全的”--这里的“安全”是指“在密钥保持机密时安全”

第二个问题：是否“机密”值始终为16位

我猜这指的是“秘密密钥”，也称为“共享秘密”——所以数字指的是字节

RFC第4节“算法要求”包括：

R6-算法必须使用强共享秘密。共享秘密的长度必须至少为128位。本文档建议共享密钥长度为160位

---

所以小于16字节的“秘密”是不一致的。

嘿，还有一个问题。所以任何大于16字节的都可以？因为我刚刚看到google authenticator接受长度为“length%8==0”的所有机密。所以它也会接受长度为8的秘密。。它符合规格吗？有没有像64这样的最大长度？共享秘密被输入SHA-1 HMAC。SHA-1块大小为160位，因此较短的共享密钥将零扩展到160位，较长的共享密钥将通过SHA-1“压缩”到160位。因此，从表面上看，一个更长时间的共享秘密并没有增加多少。提醒你，如果你有一个低熵的共享秘密，那么时间越长越好。。。尽管你可以将其分解为160位（更高的熵）。我决不会对谷歌的代码发表评论。。。我注意到

length%8==0

本身也会接受

length==0

！是否有其他关于

长度的检查？假设提供者（例如google authenticator）允许使用sha1、SH256和SH512。对于共享机密，什么是好的验证规则？只有16个字节？16、20和24岁？