登录时应该使用随机数吗?

S. *_*ont 1 security authentication hash login nonce

Wikipedia提供了以下基于 nonce 的身份验证示例:

  1. 客户端从服务器请求随机数。

  2. 服务器以随机数响应(即,以下称为“服务器随机数”)。

  3. 客户端使用服务器随机数、它自己的客户端随机数和用户输入的密码来生成哈希。

  4. 客户端将用户输入的用户名、客户端随机数和哈希发送到服务器。

  5. 服务器从其数据库中检索服务器随机数和用户密码,大概是通过用户名。

  6. 服务器结合服务器随机数、客户端随机数和密码来生成哈希。

  7. 服务器将刚刚生成的散列与客户端发送的散列进行比较。

  8. 如果哈希匹配,则客户端通过身份验证。如果不是,则客户端被拒绝。

这是否意味着服务器以纯文本形式存储用户密码?是否严重违反了建议保存密码的加盐哈希而不是实际密码本身的安全原则?

Gum*_*mbo 8

该协议基本上是一种质询-响应认证。它用于避免发送实际的秘密(例如,密码),但响应只能在知道秘密的情况下有效。并且为了避免重放攻击,加入了一个随机数。

然而,上述协议要求服务器以可检索的形式(例如,明文或加密)存储秘密。

但是您可以通过要求客户端生成相同的密码散列来更改协议以允许使用密码散列而不是明文密码:

  1. 客户端从服务器请求用户输入的用户名的salt和 nonce 。
  2. 服务器从其数据库中检索salt,大概是通过username,并以salt和 nonce(即,以下称为server nonce)响应。
  3. 客户端使用salt和用户输入的密码来生成密码哈希,并使用密码哈希服务器 nonce和它自己的客户端 nonce来生成nonce hash
  4. 客户端将用户输入的usernameclient noncenonce hash发送到服务器。
  5. 服务器从其数据库中检索服务器随机数和用户密码哈希,大概是通过username
  6. 服务器结合服务器随机数客户端随机数密码哈希来生成随机数哈希
  7. 服务器将刚刚生成的nonce hash与从客户端发送的nonce hash进行比较。
  8. 如果哈希匹配,则客户端通过身份验证。如果不是,则客户端被拒绝。

  • 很好的解释,但有一个简短的说明:我不建议客户端将“服务器随机数”发回。这将允许中间人攻击,因为他可以只替换随机数,而如果服务器存储它直到客户端响应,则随机数不能在服务器端修改,现在如果它在通信期间被修改,随机数散列将't match(因为随机数在客户端和服务器上会不同)。 (2认同)