我正在审核加密质询 - 响应协议的实施。密码用作加密加密nonce（挑战）的密钥，并将结果与响应进行比较。
目前，nonce并不是真正安全的，因为它是通过srand()和rand()获得的。随机数种子的所有成分（以秒为单位的当前时间（！）和pid）很容易猜到中间的人。这显然不是很好，但我的问题是，这在防止重放攻击方面有多糟糕？是否应该从CSPRNG（例如/ dev / urandom）获得挑战？有没有人指出最佳做法？
答案 0 :(得分：1)
如果您担心挑战不够随机和/或无法预测，那么总会将您想到的所有内容添加到（长字符串）并计算单向散列。
所以伪随机数，time（），连接的IP地址，源端口号，用户名，挑战生成器保密的长字符串，pid，...越多越好。
如果其中任何一个发生变化，结果哈希会发生显着变化，并且在那里给出长字符串......在挑战变得可预测之前，需要猜测它或反转哈希值。
它也带来了相当独特的挑战（您需要在哈希中找到冲突，以使挑战不唯一）。
那就是说，如果重复出现挑战的几率（伪随机数发生器就是恕我直言），我认为挑战的目的已经达到了。
在基于挑战的身份验证方案中，我会担心的是在服务器上存储密码。它可以通过盐渍存储和缓慢的哈希来完成，但许多实现只是存储共享的秘密，而且恕我直言的确是个坏主意。
参考盐渍挑战响应计划：https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism
答案 1 :(得分：0)
如果您的哈希和密码都很好，那么挑战是否可预测并不重要。一旦提交了公共知识，就面临挑战。最重要的是永远不要重复挑战，因为反应可能被截获。
正如我所看到的，如果你可以保持单调递增，那么简单的递增nonce就可以在这里工作。
或许这里有一些我不明白的漏洞？