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

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

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

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

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

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

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

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

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

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

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

我不擅长密码学，如果我错了，请纠正我。

Answer 6

@CodeDog 示例有问题..

是的，我可以相信用户会登录自助餐厅。如果您正在从公司食堂捕获日志，那么您就是安全漏洞。公司食堂的包厢应设置为禁用，例如无条款、无记录器、无远程访问等。以防止您，内部黑客。

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

此外，如上所述，公共计算机黑客攻击是通过使系统免受威胁来保护的。例如，将 chromebook 用于公共自助餐厅的计算机。但这可以通过物理黑客绕过。下班时间，去自助餐厅设置一个秘密摄像头来记录用户的键盘按下情况。那么自助餐厅的计算机是否瘫痪或使用什么类型的加密都无关紧要。

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

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

Answer 7

其他海报是正确的.既然您正在使用SSL来加密密码的传输,请确保使用良好的算法和盐对其进行散列,以便在静止时对其进行保护......