在通过HTTPS发送密码之前进行哈希处理是否必要？

Question

我对Web开发（今年1月开始）和Web安全（不到一周）都很陌生，如果我的问题非常幼稚、错误或者简单得让人觉得无聊，请原谅。

我们公司的主要产品是一个传统的客户端/服务器系统。为了使其更具吸引力，我被分配开发一堆基于简单任务的Web应用程序，以补充该系统整个业务流程为中心的设计。例如，如果用户在组织中的角色是批准采购订单和付款订单，他们可能会发现使用WebApprovals应用程序比打开Purchases和Treasury模块并使用它们来分别批准采购订单和付款订单更容易。

不用说，我所有的Web应用程序都有一个登录页面。当然，我需要它们是安全的。出于这个原因，按照设计，这些Web应用程序只能通过HTTPS使用，永远不能通过普通的HTTP使用。

现在，我想知道在没有任何其他安全措施的情况下通过HTTPS发送密码有多安全。它足够安全吗？有经验的安全领域人士有什么说法？

- pyon

Answer 1

HTTPS将处理传输安全性，因此没有理由在客户端对其进行哈希。如果这样做，则从服务器的角度来看，哈希密码本质上就变成了真实密码。如果有人窃取了您的数据库，每一行数据都会包含服务器期望从网络接收的值。攻击者可以简单地创建一个新客户端，直接发送哈希而不必使用任何真正的哈希。

然而，通过网络发送的密码不应该存储在数据库中。相反，应该有一个每个用户独有的随机盐。这个盐应该在服务器端用于哈希密码。

参见密码加盐：最佳实践？。

- Matthew Flaschen

---

@Matthew：我不太理解随机加盐的工作原理。如何验证用户密码与包含随机盐的哈希值匹配？ - isekaijin

@Eduardo，您将每个用户的盐和哈希值都存储在数据库中。它们都不是真正的机密。然后，您对存储的盐和提供的密码进行哈希处理，并将结果与存储的哈希值进行比较。请参阅此文章。您还可以在Stack Overflow上搜索更多信息。 - Matthew Flaschen

只是为了澄清，即使哈希和盐被破解，密码仍应该具有抵御破解的能力。但是，您仍然不会故意泄露任何一个。至于像用户ID这样的非公钥，它仍然可以促进查找表的使用。例如，小型网站往往会有较低的用户ID，因此可以专门构建攻击从1到1000的盐的彩虹表。随机值更安全。 - Matthew Flaschen

@Eduardo，我写了一篇文章：http://dustwell.com/how-to-handle-passwords.html，其中更详细地解释了每个用户盐值的事情。 - Dustin Boswell

@Eduardo，好的。NEWID不会返回均匀随机值，但我认为它可能“足够随机”。 - Matthew Flaschen