技术上有两个问题 - 但它们是如此密切相关，我不想将它们分开;但如果社区觉得我应该，我会的。
关注recent question我正在为网站登录和Web服务API实施SCRAM。客户端环境将是.Net和Javascript（将来可能使用Java）。
我的第一个问题是基本问题：The protocol utilises a client and server key作为身份验证过程的关键步骤;然而，为了得到验证，两者都需要提前双方都知道，因为协议不允许交换这些（这样做会导致一些鸡蛋和鸡蛋的情况）。例如，如果您考虑使用Javascript客户端，这意味着这两个键可能都是源中定义的常量 - 从而使它们易于获取。那么：为什么要这么麻烦？是否只是为了减轻“夏娃”，因为某些原因，“夏娃”并没有费心去获取JS或客户端源代码，这些代码必然是公开的！？
其次，与几乎任何其他身份验证机制一样，它需要客户端+服务器现时。
鉴于根据定义，身份验证随机数不应多次使用（至少由同一用户使用），这可能意味着服务器必须维护所有用户永久使用的所有现时值的记录。与我们定期存档的其他数据不同，这样的表只会变得越来越大，对它的查询可能会越来越慢！
如果这是正确的，那么实现这个或几乎任何其他认证机制在技术上是不可行的！因为我知道这显然是荒谬的;在一个合理的时间范围内定义一些额外的范围也必须是常见的。
与身份验证和加密一样;尽管我是一位非常有经验的软件开发人员，但我觉得我要回到学校了！我错过了什么！？
答案 0 :(得分：2)
双方都需要知道 因为协议没有提前 允许交换这些（这样做 会导致一点鸡肉和 鸡蛋情景）。
是的，这是正确的。挑战响应不是密钥交换协议。它只是规范，一旦客户端和服务器共享一个密钥，如何从该密钥计算相同的值，而不通过网络清除密钥。
如果您考虑使用Javascript客户端， 例如，这意味着两个键都是 可能是在中定义的常数 来源 - 从而使它们变得容易 取。
这不是个好主意。或者，客户端和服务器可以在初步注册过程中就密钥达成一致。
鉴于认证nonce， 根据定义，永远不应该使用 不止一次（至少是相同的 用户），这可能意味着一个 服务器必须保留所有记录 所有用户使用的nonce值 永远。
NO。应使用伪随机数生成为每个新会话生成新的随机数。你不可能两次获得相同的nonce，无论如何，如果攻击者不知道如果已经使用了nonce，则无关紧要。