HTTPS上的纯文本密码

我目前正在使用一个PHP OpenID提供程序，它将通过HTTPS（因此SSL加密）工作。

---

我用纯文本传输密码是错误的吗？理论上，HTTPS不能被截获，所以我看不出任何错误。或者这在某种程度上是不安全的，我看不到这一点吗？

如果禁用了HTTP，而您只使用HTTPS，那么您实际上并没有以纯文本形式传输密码。

这是安全的。这就是整个网络的工作方式。表单中的所有密码始终以纯文本形式发送，因此需要使用HTTPS来确保其安全。

您仍然需要确保通过POST请求而不是GET发送密码。如果通过GET请求发送，则可以将其以明文形式保存在用户的浏览器历史记录日志或Web服务器的访问日志中。

其他海报是正确的。现在，您正在使用SSL加密密码的传输，请确保使用良好的算法和salt对其进行哈希运算，以便在密码处于静止状态时对其进行保护

散列客户端。为什么？ 让我告诉你一个小实验。 走到公司自助餐厅的电脑前。打开浏览器至公司网站登录页（https）。 按F12键，单击“网络”选项卡，勾选“持久化日志”，最小化控制台，但保持网页对登录页打开。 坐下来吃午饭。当员工登录到公司网站后，作为一名优秀的小员工，当员工登录完成后，将注销。 吃完午饭，坐在电脑旁，打开网络标签，在表格Body中以明文形式查看每个用户名和密码

没有特殊的工具，没有特殊的知识，没有奇特的黑客硬件，没有键盘记录器，只有好的旧F12

---

但是，请继续思考，您需要的只是SSL。坏人会因此爱上你的。

让我们对之前的答案做一些笔记

首先，在客户端使用哈希算法可能不是最好的主意。如果您的密码被放在服务器端，您将无法比较散列（至少如果您没有将客户机散列存储在数据库中的某个散列层中，这与密码相同或更糟），那么您将无法比较散列。如果您不想在客户端实现数据库使用的散列算法，那就太傻了

其次，交换加密密钥也不理想。理论上，MITM可以（考虑到他在客户端上安装了根证书）更改加密密钥，并使用自己的密钥进行更改：

来自交换密钥的理论服务器的原始连接（不考虑tls）：

客户端请求公钥>服务器持有私钥，向客户端生成公钥>服务器向客户端发送公钥

现在，在一个理论上的MITM atrack中：

客户端请求公钥>MITM生成伪私钥>服务器持有私钥，向客户端生成公钥>MITM从原始服务器接收公钥，现在，我们可以自由地向客户端发送伪公钥，每当客户端发出请求，我们将使用假密钥解密客户端数据，更改有效负载（或读取它），并使用原始公钥进行加密>MITM向客户端发送假公钥

这就是在TLS中拥有受信任的CA证书的意义所在，这就是如果证书无效，您将从浏览器收到警告消息的方式

对OP的回应：在我看来，你不能这么做，因为迟早有人会想从你的服务中攻击一个用户，并试图破坏你的协议

然而，您可以做的是实现2FA，以防止人们尝试使用相同的密码登录。不过，要警惕重播攻击

---

我对密码学不在行，如果我错了，请纠正我。

@CodeDog示例有问题

是的，我相信用户会登录到咖啡馆。如果您从公司咖啡馆捕获日志，那么您就是安全漏洞。应禁用公司咖啡盒设置，例如无条款、无记录者、无远程访问等，以防止您成为内部黑客

这是一个很好的计算机访问安全示例，与网络安全无关。它是作为客户端散列的理由提供的，但是如果您有计算机访问权限，您可以使用击键记录器并绕过它。客户端散列也是不相关的。@CodeDog的例子是一种计算机访问黑客，需要不同于网络层黑客的技术

此外，如上所述，通过削弱系统免受威胁，可以保护公共计算机黑客。e、 g.在公共咖啡馆电脑上使用chromebook。但这被物理黑客绕过了。在非工作时间，去咖啡馆，设置一个秘密摄像机来记录用户按下键盘的动作。那么，无论Caffeeteria计算机是否损坏，或者使用何种类型的加密都无关紧要

物理层->计算机层->客户端层->网络层->服务器层

---

对于网络，在客户端散列并不重要，因为https/ssl层将加密普通密码。因此，正如其他人提到的，如果TLS是安全的，那么客户端哈希是多余的。

是的，我意识到这一点，谢谢，我只是指这里的传输。细微的挑剔：一些登录表单使用JavaScript对密码进行哈希，而不是发送纯文本。@Thorarin如果他们真的对密码进行哈希，这意味着服务器将密码存储为纯文本，这样它就可以使用相同的salt进行哈希验证。哎呀！以ssl包装的文本发送密码更好，因为服务器不需要以纯文本存储密码。@DGM:双重哈希也是一个选项，因此纯文本密码不是绝对必要的。@Denis:客户端哈希没有多大帮助。它可能会使事情比纯文本更难，但真正想窃取密码的人可以毫无问题地做到这一点。只有这样才能安全