HTTPS上的纯文本密码

Question

我目前正在开发一个可以通过HTTPS工作的PHP OpenID提供程序（因此是SSL加密的） 对于我来说，将密码作为纯文本传输是错误吗？理论上HTTPS，不能被截获，所以我没有看到任何错误。或者这在某种程度上是不安全的，我没有看到这个？

Answer 1

很安全。这就是整个网络的运作方式。表单中的所有密码始终以纯文本形式发送，因此最多使用HTTPS来保护它。

Answer 2

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

Answer 3

如果禁用HTTP，并且仅使用HTTPS，那么您实际上并不是以纯文本形式传输密码。

Answer 4

哈希客户端。为什么？ 我来告诉你一个小实验。 在公司自助餐厅走到电脑前。打开浏览器到公司网站登录页面（https）。 按F12，单击网络选项卡，勾选持久日志，最小化控制台但保持网页打开登录页面。 坐下来吃午饭。在员工登录公司网站后成为员工，成为一名优秀的小工作人员。 吃完午餐，坐在电脑前打开网络标签，然后以bodys的形式查看纯文本中的每个用户名和密码。

没有特殊的工具，没有特殊的知识，没有花哨的黑客硬件，没有键盘记录器只是老F12。

但是，嘿，继续认为你所需要的只是SSL。坏人会爱你。

Answer 5

其他海报是正确的。既然您正在使用SSL加密密码的传输，请确保使用良好的算法和盐对其进行哈希处理，以便在静止时对其进行保护，太......

Answer 6

让我们对以前的答案做一些记录。

首先，在客户端使用哈希算法可能不是最好的主意。如果您的密码是在服务器端使用的，则您将无法比较哈希值（至少如果您不将客户端哈希值存储在数据库中位于密码的哈希层之一中），则密码是相同的，或者更差）。而且您不想实现客户端数据库使用的哈希算法，这很愚蠢。

第二，权衡加密密钥也不理想。从理论上讲，MITM可以（考虑到他在客户端上安装了根证书）更改密码密钥，并使用自己的密钥进行更改：

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

客户端请求公用密钥>服务器保留专用密钥，为客户端生成公用密钥>服务器将公用密钥发送给客户端

现在，在理论上的MITM轨道中：

客户端请求公钥> MITM生成伪造的私钥>服务器持有私钥，为客户端生成公钥> MITM从原始服务器接收公钥，现在，我们可以免费将伪造的公共密钥发送给客户端，并且每当客户端发出请求时，我们都会使用伪造的密钥解密客户端数据，更改有效负载（或读取有效载荷）并使用原始的公开密钥加密> MITM将伪造的公钥发送给客户端。

这就是在TLS中拥有受信任的CA证书的关键所在，这就是当证书无效时，您会从浏览器收到警告消息的方式。

作为对OP的回应：根据我的拙见，您不能这样做，因为迟早有人会想从您的服务中攻击用户并试图破坏您的协议。

但是，您可以执行2FA，以防止人们尝试使用相同的密码登录。不过请注意重放攻击。

我对密码学不是很好，如果我错了，请纠正我。

Answer 7

@CodeDog示例有问题。

是的，我可以相信用户会登录到caffeteria框。如果要从公司的咖啡店捕获日志，则 you 是安全漏洞。公司的自助餐厅框应设置为禁用，例如没有条款，没有记录程序，没有远程访问权限等。为了阻止您，内部黑客。

该示例是计算机访问安全性的一个很好的例子，与网络安全性没有真正的关系。它是作为客户端哈希的理由提供的，但是，如果您具有计算机访问权限，则可以使用按键记录器并绕过它。客户端哈希再次无关紧要。 @CodeDog的示例是计算机访问黑客，需要使用与网络层黑客不同的技术。

如上所述，通过破坏系统免受威胁也可以保护公共计算机黑客。例如在公共自助咖啡机上使用Chromebook。但这是被物理黑客绕过的。在下班时间，进入自助餐厅并设置一个秘密摄像头，以记录用户的键盘按压。然后，不管咖啡机计算机是否瘫痪，或者使用哪种类型的加密都没关系。

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

对于网络而言，是否在客户端进行哈希无关紧要，因为https / ssl层将对普通的passwd进行加密。因此，就像其他人提到的那样，如果TLS安全，则客户端哈希是多余的。