在通过HTTPS发送密码之前，是否需要对密码进行散列？

我对网络开发（今年一月开始）和网络安全（不到一周前开始！）都是新手，所以如果我的问题是没有受过教育、信息错误或简单愚蠢，请原谅

我工作的公司的主要产品是一个很好的老式客户机/服务器系统。为了让它对我们的客户更具吸引力，我的任务是开发一系列简单的以任务为中心的Web应用程序，以补充系统的整个以业务流程为中心的设计。例如，如果用户在组织中的角色包括批准采购订单和付款订单，则他们可能会发现使用WebApprovals应用程序比同时打开采购和资金模块并分别使用它们批准采购订单和付款订单更容易

不用说，我所有的Web应用程序都有一个登录页面。当然，我需要他们的安全。因此，根据设计，这些Web应用程序只能通过HTTPS使用，而不能通过普通HTTP使用

---

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

HTTPS将处理传输安全，因此没有理由在客户端对其进行哈希处理。如果这样做，从服务器的角度来看，散列密码本质上就是真实的密码。如果有人窃取了您的数据库，那么每一行都将具有服务器期望通过网络接收的值。攻击者只需创建一个直接发送散列的新客户端，而不必进行任何真正的散列

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

---

看。

@Matthew:我真的不明白随机腌制是如何工作的。如何根据包含随机salt的哈希值验证用户密码？@Eduardo，您将每个用户的salt和哈希值都存储在数据库中。两者都不是真正的秘密。然后，对存储的salt和提供的密码进行散列，并根据存储的散列检查结果。看见您还可以搜索堆栈溢出以获取更多信息。只是为了澄清一下，即使哈希和salt被破坏，密码仍然应该能够抵抗破解。不过，你也不会故意透露。对于像UserId这样的非公钥，这仍然有助于查找表的使用。例如，小型站点的用户ID往往较低，因此可以专门构建从1到1000的rainbow表。随机值更安全。@Eduardo，我写了一篇文章：这篇文章更详细地解释了每用户盐的问题。@Eduardo，好的。NEWID不会以随机值统一返回，但我认为它可能“足够随机”