认证阶段的盐暴露答案

【问题标题】：Salt exposure in authentication stages认证阶段的盐暴露
【发布时间】：2010-02-25 20:31:19
【问题描述】：

我已经实现了如下所示的多阶段身份验证。

方括号（[ 和 ]）表示哈希

客户端有一个 key 和一个 secret 用于身份验证。服务器有一个数据库表，其中的行包含 key、salt 和 [secret + salt]

       Client                                    Server
         |                                          |
         ----------------- key -------------------->| 
         |                                          | 
         |                                          |
         |<--------- server-nonce -------------------
         |<------------ salt ------------------------
         |                                          |
         |                                          |
         ------------ key ------------------------->|
         ------------ client-nonce ---------------->|
         --[c-nonce + s-nonce + [secret + salt]] -->|
         |                                          |

然后服务器根据自己的信息检查收到的哈希值。

我担心的是，这使攻击者能够从服务器获取盐，然后生成彩虹表来破解该帐户。您对此有何看法？

【问题讨论】：

标签： authentication salt

【解决方案1】：

你是对的。如果攻击者知道系统是这样工作的，就有机会捕获数据并破解。它不安全。

当有许多其他系统（SSL、公钥身份验证等）没有这些陷阱时，我不明白你为什么要走这条路。

【讨论】：

我知道我正在重新发明轮子。这样做的原因之一是为了学习。

【解决方案2】：

为什么需要将盐返回给客户？纯粹是为了保护用户的秘密？无论如何，c-nonce 和 s-nonce 都会被传输，因此只有 [secret + salt] 组合被隐藏。

我的感觉是，如果它是一次性的盐，那就没关系了——你只接受对那个盐的单一响应，如果它失败了，就会生成一个新的盐并再次经历这个过程。这样一来，如果 salt 被拦截，彩虹表攻击就不可能了，因为它只对第一个请求有效，所以他们需要一个非常幸运的猜测。

您还可以通过使用渐进式超时或限制登录次数等技术来避免此类攻击，这些技术对用户影响很小，但肯定会给任何尝试运行数百次登录尝试的自动化工具带来问题。如果安全性对您很重要，这可能还是值得实施的。

【讨论】：

【解决方案3】：

如果连接不安全，并且攻击者设法获得了盐和密码，即使没有彩虹表，他也可以粗暴地破解帐户。

单独的盐\密码是没用的。

算法应该更像：

client-----pass------>server
client<----noonce----server
                     server--------getSalt---->back-end-service
                     server<-------salt------- back-end-service
                     server-------[pass+salt]->storage

【讨论】：