通过 HTTPS 的纯文本密码
我目前正在开发一个 PHP OpenID 提供程序，该提供程序将通过 HTTPS 工作（因此采用 SSL 加密）。
我以纯文本形式传输密码是否错误？ HTTPS理论上是不能被拦截的，所以我没看出有什么问题。 或者这在某种程度上不安全而我没有看到这一点？
I'm currently working on a PHP OpenID provider that will work over HTTPS (hence SSL encrypted).
Is it wrong for me to transmit the password as plain text? HTTPS in theory, cannot be intercepted, so I don't see anything wrong. Or is this unsafe at some level and I'm failing to see this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这是安全的。 这就是整个网络的运作方式。 表单中的所有密码始终以纯文本形式发送，因此由 HTTPS 来保证其安全。
It is safe. That's how the entire web works. All passwords in forms are always sent in plain text, so its up to HTTPS to secure it.
您仍然需要确保通过 POST 请求而不是 GET 发送它。 如果您通过 GET 请求发送它，它可能会以明文形式保存在用户的浏览器历史记录日志或网络服务器的访问日志中。
You still need to make sure you send it via POST request, not GET. If you send it via GET request, it could be saved in plaintext in the user's browser history logs or the webserver's access logs.
如果 HTTP 被禁用，并且您仅使用 HTTPS，那么您实际上并没有以纯文本形式传输密码。
If HTTP is disabled, and you only use HTTPS, then you're not really transmitting the password as plain text anyway.
哈希客户端。 为什么？
让我告诉你一个小实验。
走到公司食堂的电脑前。 打开浏览器访问公司网站登录页面 (https)。
按 F12，单击网络选项卡，选中持久日志，最小化控制台但保持网页打开以登录页面。
坐下来吃午饭。 观察员工一个接一个地登录公司网站，并在完成后注销。
吃完午餐，坐在电脑前打开网络选项卡，然后以纯文本形式查看表单正文中的每个用户名和密码。
没有特殊的工具，没有特殊的知识，没有花哨的黑客硬件，没有键盘记录器，只有老式的 F12。
但是，嘿，请继续思考您所需要的只是 SSL。 坏人会因此而爱你。
Hash client side. Why?
Let me tell you about a little experiment.
Walk up to computer in company cafeteria. Open browser to company web site login page (https).
Press F12, click network tab, check off persist log, minimize console but leave web page open to login page.
Sit down and eat lunch. Watch as employee after employee logs on to the company web site and being a good little worker logs out when done.
Finish lunch, sit down at computer bring up network tab and see every single username and password in plain text in the form bodys.
No special tools, no special knowledge, no fancy hacking hardware, no keyloggers just good old F12.
But hey, keep thinking all you need is SSL. The bad guys will love you for it.
让我们对之前的答案做一些笔记。
首先，在客户端使用哈希算法可能不是最好的主意，因为如果您的密码在服务器端加盐，您将无法比较哈希值（至少如果您不在数据库中存储客户端哈希值的话）在密码的哈希层之一中，这是相同或更差）。 而且您不想在客户端实现数据库使用的哈希算法，这将是愚蠢的。
其次，权衡加密密钥也不是理想的选择。 理论上，MITM 可以（考虑到他在客户端上安装了根证书）更改加密密钥，并使用他自己的密钥进行更改：
来自交换密钥的理论服务器的原始连接（不考虑 TLS）的示例：
客户端请求公钥> 服务器持有私钥，生成公钥给客户端>> 服务器将公钥发送给客户端
现在，在理论上的 MITM atrack 中：
客户端请求公钥 > MITM 生成假私钥 > 服务器持有私钥，生成公钥给客户端>> MITM从原始服务器接收公钥，现在，我们可以随意将假公钥发送给客户端，每当客户端发出请求时，我们都会用假密钥解密客户端数据，更改有效负载（或读取它）并使用原始公钥进行加密 > MITM 向客户端发送伪造的公钥。
这就是在 TLS 中拥有受信任的 CA 证书的意义所在，如果证书无效，这就是您从浏览器收到警告消息的方式。
回应OP：以我的拙见，你不能这样做，因为迟早有人会想要攻击你的服务中的用户，并试图破坏你的协议。
然而，您可以做的是实施 2FA 以防止人们尝试使用相同的密码登录。 但要小心重放攻击。
我对密码学不是很擅长，如果我错了，请纠正我。
Let’s make some notes to previous answers.
First, it’s probably not the best idea to use hash algorithms client side because if your password is salted on the server side, you won’t be able to compare hashes (at least not if you don’t store the client hash in the database in one of the hashing layers from the password, which is the same or worse). And you don’t want to implement the hashing algorithm used by the database on the client side, it would be silly.
Second, trading off cryptographic keys aren’t ideal either. The MITM could theoretically (considering he has a root cert installed on the client) change the cryptographic keys, and change with his own keys:
Example from an original connection (not considering TLS) from a theoretical server that exchanges keys:
Client request public keys > server holds the private keys, generate public keys to client > server sends public keys to client
Now, in a theoretical MITM atrack:
Client request public keys > MITM generates fake private keys > Server holds the private keys, generate public keys to client > MITM receives the public keys from the original server, now, we’re free to send our fake public keys to the client, and whenever a request comes from the client, we will decrypt the client data with the fake keys, change the payload (or read it) and encrypt with the original public keys > MITM sends fake public keys to client.
That’s the point of having trusted CA certificate in TLS, and that’s how you receive a message from the browser warning if the certificate isn’t valid.
In response to the OP: in my humble opinion you can’t do that, because sooner or later, someone will want to attack a user from your service and will try to break your protocol.
What you can do, however, is to implement 2FA to prevent people from ever trying to login with the same password. Beaware of replay attacks, though.
I’m not great with cryptography, please correct me if I’m wrong.
其他海报是正确的。 既然您正在使用 SSL 来加密密码的传输，请确保使用良好的算法和盐对其进行哈希处理，以便在静态时密码受到保护，也...
The other posters are correct. Now that you're using SSL to encrypt the transmission of the password, make sure you're hashing it with a good algorithm and salt so it's protected when it's at rest, too...
@CodeDog 示例有问题。
是的，我可以相信用户会登录到自助餐厅。 如果您正在从公司食堂捕获日志，那么您就是安全漏洞。 公司食堂的包厢应设置为禁用，例如无条款、无记录器、无远程访问等。以防止您成为内部黑客。
该示例是计算机访问安全的一个很好的示例，与网络安全并没有真正的关系。 它是作为客户端散列的理由而提供的，但如果您有计算机访问权限，则可以仅使用击键记录器并绕过它。 客户端哈希再次无关紧要。 @CodeDog 的示例是计算机访问黑客，需要与网络层黑客不同的技术。
此外，如上所述，公共计算机黑客攻击是通过使系统免受威胁来保护的。 例如，将 chromebook 用于公共自助餐厅的计算机。 但这可以通过物理黑客攻击来绕过。 下班时间，去自助餐厅设置一个秘密摄像头来记录用户的键盘按下情况。 那么自助餐厅的计算机是否瘫痪或使用什么类型的加密都无关紧要。
物理层-> 计算机层-> 客户端层-> 网络层-> 服务器层
对于网络，如果您在客户端散列并不重要，因为 https/ssl 层将加密纯密码。 因此，正如其他人提到的，如果 TLS 是安全的，则客户端哈希是多余的。
@CodeDog example has issues..
Yes, I can believe that users will log into a caffeteria box. If you are capturing logs from a corporate caffeteria, then you are the security breach. Corporate caffeterias boxes should be setup disabled, e.g. no terms, no loggers, no remote access, etc. In order to prevent you, the inside hacker.
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.