107

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

4

7 回答 7

143

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

于 2009-06-07T16:11:12.607 回答
88

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

于 2009-06-07T16:31:34.907 回答
24

如果 HTTP 被禁用，并且您只使用 HTTPS，那么无论如何您并没有真正将密码作为纯文本传输。

于 2009-06-07T16:11:07.647 回答
22

哈希客户端。为什么？让我告诉你一个小实验。走到公司食堂的电脑前。打开浏览器到公司网站登录页面 (https)。按 F12，单击网络选项卡，检查持久日志，最小化控制台，但保持网页打开到登录页面。坐下来吃午饭。在员工登录公司网站后作为员工观看，并在完成后作为一名优秀的小员工退出。吃完午饭，坐在电脑前打开网络选项卡，在表单正文中以纯文本形式查看每个用户名和密码。

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

但是，嘿，继续想你所需要的只是 SSL。坏人会因此爱上你。

于 2017-07-21T08:11:28.757 回答
7

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

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

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

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

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

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

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

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

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

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

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

于 2018-08-24T05:22:18.650 回答
5

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

于 2009-06-07T16:36:30.910 回答
4

@CodeDog 示例有问题..

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

The example is a good one of computer access security, and not really related to network security. It is provided as justification for client side hashing, but if you have computer access you could just use a keystroke logger and bypass that. The client side hash is again irrelevant. The example by @CodeDog is a computer access hack and requires techniques different from network layer hacks.

Also, a public computer hack is protected by crippling the system from threats, as mentioned above. e.g. use a chromebook for a public caffeteria computer. But that is bypassed by a physical hack. During off hours, go to the caffeteria and setup a secret camera to record keyboard presses by users. Then it doesnt matter if the caffeteria computer is crippled, OR what type of encryption is used.

physical layer -> computer layer -> client layer -> network layer -> server layer

For networking, doesnt matter if you hash on client side because the https/ssl layer will encrypt the plain passwd. So as others mention the client hashing is redundant if the TLS is secure.

于 2020-08-24T20:06:40.100 回答