【问题标题】:nonce usage in authentication身份验证中的 nonce 用法
【发布时间】:2011-06-30 08:56:01
【问题描述】:

在基于摘要的身份验证中,nonce 由服务器生成。但是在基于 OAuth 的身份验证中,nonce 是由客户端生成的。我想知道是否有人知道差异的原因?

【问题讨论】:

    标签: security http oauth nonce


    【解决方案1】:

    首先,有时客户端确实在摘要身份验证中提供随机数,但主要依赖于服务器(请参阅 RFC2617)

    其次,因为如果您从握手的角度来考虑身份验证过程,那么使用 Oauth 当您已经拥有令牌时,您已经完成了一半的握手,您已经与服务器进行了交谈,所以您的下一个move 是用您的服务请求联系服务器。这也需要由 nonce 保护,所以你提供它。

    或者,反过来。我已经有了令牌,那我为什么要联系服务器来获得一个随机数,以便我可以再次联系服务器并提出我的服务请求呢?我可能会发出 1000 个服务请求,通过生成我自己的 nonce,它会减少 2000 位不需要的网络流量。

    【讨论】:

      【解决方案2】:

      Nonce 用于使请求具有唯一性。在没有随机数的身份验证方案中,恶意客户端可以生成一次请求并重播多次,即使计算成本很高。如果身份验证模式要求客户端为每个请求执行昂贵的计算,因为请求是通过使用 nonce 使请求唯一的,那么重放攻击就会被折叠,因为它的速度刚刚从 O(1) 变为 O(N)。

      拥有客户端随机数的原因是为了防止恶意客户端进行重放攻击。
      拥有服务器随机数的原因是为了防止中间人攻击,以防攻击者捕获有效的服务器响应并尝试将其重播给客户端。

      http://en.wikipedia.org/wiki/Cryptographic_nonce 对如何使用 nonce 有很好的解释和图表。

      http://en.wikipedia.org/wiki/Digest_access_authentication 有一个很好的例子来说明如何在现实世界中使用随机数。

      【讨论】:

      • 我不明白。是什么阻止了恶意客户端多次发送他生成一次的nonce?当服务器收到已使用的nonce 时,是否应该拒绝请求?
      • 没什么,恶意客户端可以做到这一点没问题。这不是随机数保护的场景。它们保护非恶意用户的登录信息不会被恶意窥探者重放。
      猜你喜欢
      • 2017-10-11
      • 2021-08-05
      • 1970-01-01
      • 2013-05-30
      • 1970-01-01
      • 2020-10-31
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多