为什么不使用散列密码作为密码？

Question

为什么我们不使用我们的手机哈希密码，然后输入一个网站上的哈希作为密码？

这样，网站的密码就会复杂得多。

这会增加安全吗？

示例

1. 手机: p4ssword --散列->527 fcfb9b03f2813eadd840a2ae0fb56
2. 网站:输入'527fcfb9b03f2813eadd840a2ae0fb56‘作为密码。

Answer 1

这在本质上与生成没有散列的密码在安全性方面是一样的。无论您是否使用您的名字作为密码或当前时间的校验和，都不重要；如果您在Internet上发送的内容与服务器端直接存储在列表中的字符串进行比较，那么密码就不会被有效地散列。

在服务器端(即使“服务器”是本地的)使用散列存储密码的要点是，一个好的散列算法是单向的。所以，如果这个列表被偷了，有这个列表的人就不能直接得到密码。对散列密码的身份验证要求对提供的字符串应用一个进程，结果是相同的。因此，一组失窃的散列只提供该过程的输出，而不是授予身份验证的实际值。

但是，如果在客户端执行散列操作，则服务器端的列表是用于身份验证的实际值。这意味着，一旦列表被披露，就不需要使用这些值作为任何用户登录到应用程序中。

Answer 2

我猜这取决于服务器做什么，但它并没有增加太多的保护方式(甚至更糟)。(同样，普通用户知道如何在移动上计算哈希吗？)对我来说听起来很麻烦。)

1.服务器存储哈希密码

这意味着客户端向服务器发送H = hash(password)，服务器在DB中查找客户端哈希密码H'，并通过检查H == H'验证客户端。这真的很糟糕。现在，如果发生DB破坏，攻击者可以输入存储在数据库中的散列密码来登录。它从根本上消除了哈希点，就像明文密码被存储了一样。

2. Server存储散列密码

的哈希。

这意味着客户端向服务器发送H = hash(password)，服务器在DB中查找客户端哈希哈希密码H'，并通过检查H' == hash(H)验证客户端。现在，如果发生DB破坏，攻击者必须检查是否为hash(hash(guess)) == recovered_hash，因此攻击者的成本大约是没有客户端散列的成本的2倍(也就是说，攻击者可以检查密码速度慢50%，这并不意味着成功)。在这种情况下，安全性仍然取决于hash是一个抵抗字典攻击的(不可逆转的)函数，客户端哈希对此没有什么帮助。

总之，最好的做法是让客户机以明文形式输入密码，通过HTTPS将密码发送给服务器，并在服务器上使用类似bcrypt或scrypt之类的内容散列密码，只将哈希存储在服务器上。您的构造没有改进的原因是，如果您不会获得任何熵，并且很容易(或不容易)猜测，那么您只是在添加一个中间阶段。

Answer 3

这会增加安全吗？不是的。任何现代应用程序都已经将其密码存储在数据库中。每当进行身份验证尝试时，都会对用户输入进行散列，并将其与数据库中的内容进行比较。大多数情况下，这种情况发生在单向加密(散列不能解密回它的原始值)。

当您在移动电话上创建哈希时，有三个问题：

1. 您必须将散列密码的哈希保存在数据库中(否则数据库仍将以纯文本保存接受版本的密码)。
2. 对于用户来说，输入哈希的时间太长了，而且他/她输入错误的可能性也很大。
3. “原始”密码仍然是在(通常)互联网连接的设备上输入的，因此仍然可以被截获。

我看不出这么做对安全有什么好处。当然，您可以在双因素认证进程中使用移动电话来提高用户帐户的安全性。