我目前正在使用将通过HTTPS（因此经过SSL加密）工作的PHP OpenID提供程序。我以纯文本形式传输密码
是否错误？从理论上讲，HTTPS不能被拦截，因此我看不到任何错误。还是从某种程度上讲这是不安全的，而我却看不到呢？
Answers:
很安全 这就是整个网络的工作方式。表单中的所有密码始终以纯文本形式发送，因此由HTTPS进行保护。
您仍然需要确保通过POST请求而不是GET发送。如果通过GET请求发送，则可以将其以纯文本格式保存在用户的浏览器历史记录日志或Web服务器的访问日志中。
如果禁用了HTTP，而您仅使用HTTPS，那么无论如何您实际上都不会以纯文本形式传输密码。
哈希客户端。为什么？让我告诉你一个小实验。走到公司食堂里的电脑。打开浏览器到公司网站登录页面（https）。按F12键，单击“网络”选项卡，检查持久日志，最小化控制台，但保持网页打开状态进入登录页面。坐下来吃午餐。在员工登录到公司网站之后，请当员工观看，并在完成后成为一名好工人。吃完午饭，坐在计算机旁，打开“网络”选项卡，在表单正文中以纯文本格式查看每个用户名和密码。
没有特殊的工具，没有特殊的知识，没有花哨的黑客硬件，没有键盘记录程序，只是旧的F12。
但是，请继续考虑您所需要的只是SSL。坏家伙会为此而爱你的。
让我们对以前的答案做一些笔记。
首先，在客户端使用哈希算法可能不是最好的主意。如果您的密码是在服务器端使用的，则您将无法比较哈希值（至少如果您不将客户端哈希值存储在数据库中密码的哈希层之一中，则该哈希值是相同的，或者更差）。而且您不想在客户端上实现数据库使用的哈希算法，这很愚蠢。
其次，权衡加密密钥也不理想。从理论上讲，MITM可以（考虑他在客户端上安装了根证书）更改密码密钥，并使用自己的密钥进行更改：
来自交换密钥的理论服务器的原始连接（不考虑tls）：
客户端请求公钥>服务器持有私钥，为客户端生成公钥>服务器将公钥发送给客户端
现在，以理论上的MITM追踪：
客户端请求公钥> MITM生成伪造的私钥 >服务器持有私钥，为客户端生成公钥> MITM从原始服务器接收公钥，现在，我们可以自由地将伪造的公钥发送给客户端，并且每当来自客户端的请求时，我们将使用伪密钥解密客户端数据，更改有效负载（或读取有效载荷）并使用原始公钥加密 > MITM将伪公钥发送给客户端。
这就是在TLS中拥有受信任的CA证书的关键所在，这就是当证书无效时您如何从浏览器接收消息的警告。
针对OP：根据我的拙见，您不能这样做，因为迟早有人会想从您的服务中攻击用户并试图破坏您的协议。
但是，您可以执行2FA，以防止人们尝试使用相同的密码登录。但是要注意重放攻击。
我对密码学不是很好，如果我错了，请纠正我。
其他海报是正确的。既然您正在使用SSL加密密码的传输，请确保使用良好的算法和盐对密码进行哈希处理，以便在静止时也能对其进行保护...
@CodeDog示例有问题。
是的，我可以相信用户会登录到自助餐厅框中。如果您要从公司的咖啡店捕获日志，那么您就是安全漏洞。公司的自助餐厅应设置为禁用状态，例如，没有术语，没有记录器，没有远程访问权限等。为了防止您进入内部黑客的行列。
该示例是计算机访问安全性的一个很好的例子，与网络安全性没有真正的关系。它是作为客户端哈希的理由提供的，但是，如果您具有计算机访问权限，则可以使用按键记录器并绕过它。客户端哈希也不再相关。@CodeDog的示例是计算机访问黑客，并且要求使用与网络层黑客不同的技术。
此外，如上所述，通过破坏系统免受威胁可以保护公共计算机黑客。例如，将Chromebook用于公共咖啡机计算机。但这是被物理黑客绕开的。在下班时间，进入自助餐厅并设置一个秘密摄像头，以记录用户的键盘按压。然后，不管咖啡机计算机是否瘫痪，或者使用哪种类型的加密都没有关系。
物理层->计算机层->客户端层->网络层->服务器层
对于网络而言，是否在客户端进行哈希无关紧要，因为https / ssl层将加密普通的passwd。因此，就像其他人提到的那样，如果TLS安全，则客户端哈希是多余的。