哈希、盐和最佳做法

Question

读到关于哈希、盐和胡椒的文章，我无法理解以下情况：

如果有一个web应用程序，并且您在该站点上注册，则应该在客户端还是服务器端对密码进行散列？如果要考虑在客户端对其进行散列，还必须生成一个单独的盐类，然后将其附加到您的密码中，然后将该组合与salt一起发送到服务器，或者您也可以散列密码，将其发送到服务器，然后由服务器将salt附加到哈希中，然后再对其进行散列处理。但是，如果攻击者能够在登录期间拦截客户端和服务器之间的连接，他就不会对salt感兴趣，因为客户端只是向服务器发送散列(或明文)密码.如果攻击者能够侵入数据库，他仍然能够强行执行哈希操作。因此，据我所知，盐类只对RainbowTable攻击有用。

那最好的做法是什么？谁应该散列密码，盐应该加在哪里？

Answer 1

一般来说，盐类和散列是由服务器端完成的，而不是客户端。服务器和客户端之间的通信应该通过加密(TLS)来保护。正如安德斯在评论中提到的那样，这可能会回答你的许多问题：对于HTTPS网络应用程序，是否值得在发布之前加密密码，以防止MITM攻击者对其进行强化？

关于盐类和散列的一般情况:盐类和散列背后的想法通常归结为迫使攻击者执行一种蛮力算法。这两项措施都包括：(a)购买服务时间，以保护网络安全和更改用户密码；(b)防止公司/网站内的不良行为者获取用户密码(因为在其他网站上尝试该密码之类的顽皮行为)。

盐能做很多事情。(1)像你所说的防止彩虹表攻击，(2)在数据泄露的情况下，密码破解比普通散列更难破解(也就是说，攻击者不可能为一个算法建立一个包含所有散列的数据库；他们必须为每个散列创建数据库，这是不可行的)；这会为站点/用户争取时间来更改算法和密码，(3)防止为站点工作的人很容易地窃取用户的密码，(4)为保护身份验证过程提供更多的架构选项。

关于(4)一分钟，我的一个(非常大的国际)客户端有一个微服务体系结构，他们的身份验证过程是在将密码发送到检查实际数据库的微服务之前，先使用多个盐类(基于用户名)对密码进行散列。这种类型的分离阻止了处理数据库的代码同时知道salt和密码，并且知道salt的微服务不会保留散列(内存中和磁盘上都不会)。攻击者不能使用数据库转储；他们需要来自多台服务器的数据库和软件。这就增加了复杂性，因为被盗的数据库使它们无法接近哈希数据库；它们还需要盐类列表(来自另一台服务器)。没有员工可以访问这两台服务器，这有助于(3)。

为什么散列客户端不是超级有用的:处于中间攻击的人可以捕获客户机和服务器之间传输的任何内容。发送前对密码进行哈希处理几乎没有什么作用；攻击者不必生成哈希，他们只需再次发送完全相同的请求即可访问。

例如，让我们看看以下请求和参数(我没有使用真正的HTTP头来提高可读性)：

POST /auth/login
user=me@example.com
pass=mypassword

相对于：

POST /auth/login
user=me@example.com
pass=89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8

服务器不能通过哈希知道真正的密码是"mypassword"，所以它只使用散列来验证用户的帐户。能够读取该请求的攻击者不需要知道您的密码是"mypassword"，他们只需要接受散列；这对帐户没有任何保护。唯一可以阻止的是攻击者能够在其他网站上测试密码(例如，许多人愚蠢地为google和他们的银行使用相同的电子邮件和密码)。