通过HTTPS的纯文本密码


90

我目前正在使用将通过HTTPS(因此经过SSL加密)工作的PHP OpenID提供程序。我以纯文本形式传输密码
是否错误?从理论上讲,HTTPS不能被拦截,因此我看不到任何错误。还是从某种程度上讲这是不安全的,而我却看不到呢?

Answers:


126

很安全 这就是整个网络的工作方式。表单中的所有密码始终以纯文本形式发送,因此由HTTPS进行保护。


20
次要nitpick:某些登录表单使用JavaScript哈希密码,而不是将密码发送为纯文本。
Thorarin

5
@Thorarin如果他们真正地对其进行哈希处理,则意味着服务器将密码存储为纯文本格式,以便它可以使用相同的盐进行哈希处理以进行验证。ck!最好以ssl包装的文本形式发送密码,因为服务器无需再以纯文本形式存储密码。
DGM 2010年

11
@DGM:双重哈希也是一种选择,因此纯文本密码不是严格必需的。
Thorarin'2

3
@Denis:客户端哈希实际上并没有太大帮助。它可能使事情比纯文本要难一些,但是真正想窃取密码的人可以做到这一点没有问题。仅当您通过安全通道(ssl)发送至少一次令牌时,这种方法才能安全工作,在这种情况下,您最好只以SSL发送密码即可。
Eduardo Scoz

4
我只是说Yahoo认为客户端哈希是足够安全的,直到他们负担得起一路迁移到ssl为止。但是,嘿,我全都支持https :)
Denis

73

您仍然需要确保通过POST请求而不是GET发送。如果通过GET请求发送,则可以将其以纯文本格式保存在用户的浏览器历史记录日志或Web服务器的访问日志中。


7
是的,我知道这一点,但是留下来的其他人仍然是一个很好的评论。:)
WhyNotHugo 2014年

或将其发送到标头中
james

22

如果禁用了HTTP,而您使用HTTPS,那么无论如何您实际上都不会以纯文本形式传输密码。


4
但是,服务器确实可以访问您的纯文本密码,他们可以将其存储为纯文本,将其错误地记录为纯文本,等等。也就是说,您的密码不停留在客户端,服务器也可以准确地看到密码。
xref

12

哈希客户端。为什么?让我告诉你一个小实验。走到公司食堂里的电脑。打开浏览器到公司网站登录页面(https)。按F12键,单击“网络”选项卡,检查持久日志,最小化控制台,但保持网页打开状态进入登录页面。坐下来吃午餐。在员工登录到公司网站之后,请当员工观看,并在完成后成为一名好工人。吃完午饭,坐在计算机旁,打开“网络”选项卡,在表单正文中以纯文本格式查看每个用户名和密码。

没有特殊的工具,没有特殊的知识,没有花哨的黑客硬件,没有键盘记录程序,只是旧的F12。

但是,请继续考虑您所需要的只是SSL。坏家伙会为此而爱你的。


6
您的自助餐厅评论没有任何意义,无论我重新阅读了多少。人们为什么只走到计算机上并输入其凭证?您想证明什么?同样,无论如何,哈希不会使它变得更加不安全。在2009
。– WhyNotHugo

4
我upvoted这两个原因,是的,公认的答案被多年以后阅读。如果@CodeDog请指出一些缓解策略,那就太好了。是的,人们只是走进随机图书馆,例如在本地图书馆,然后输入他们的详细信息!
JoeAC '17

3
我使用公共密钥对客户端的密码进行加密,然后仅在表单中发布加密的密码。它是一个非对称密钥,因此拥有客户端公共密钥对攻击者毫无用处。每个日志都会生成一个新的密钥对,因此重播攻击也不会起作用。失败登录尝试时密钥甚至会更改。当用户到达登录屏幕时,将在服务器端生成密钥对。仅公共密钥提供给客户端代码。
CodeDog

顺便说一句,我已经看到有人在酒店商务中心使用这种黑客手段,以收集房间号的密码。他们将使用密码进入无线网络并使用商务中心个人电脑,并将其计入房间费用。
CodeDog

我自己登录银行帐户进行了这样的实验,必须与@CodeDog同意-请求有效负载包括我的登录名和密码(均为纯文本)。
Artur Michajluk '18年

6

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

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

其次,权衡加密密钥也不理想。从理论上讲,MITM可以(考虑他在客户端上安装了根证书)更改密码密钥,并使用自己的密钥进行更改:

来自交换密钥的理论服务器的原始连接(不考虑tls):

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

现在,以理论上的MITM追踪:

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

这就是在TLS中拥有受信任的CA证书的关键所在,这就是当证书无效时您如何从浏览器接收消息的警告。

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

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

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


请记住,这次讨论是从2009年开始的。当时,这些几乎都是最佳实践。
WhyNotHugo

3
@WhyNotHugo我知道。我决定留下一个答案,因为这个问题的Google最佳答案将我引到了这里,所以为什么不呢。
卢卡·费里

4

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


是的,我意识到这一点,谢谢,我只是在这里指的是变速箱。
WhyNotHugo

0

@CodeDog示例有问题。

是的,我可以相信用户会登录到自助餐厅框中。如果您要从公司的咖啡店捕获日志,那么就是安全漏洞。公司的自助餐厅应设置为禁用状态,例如,没有术语,没有记录器,没有远程访问权限等。为了防止您进入内部黑客的行列。

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

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

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

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


1
当您提出好要点时,您正在回答一个答案(它本身与所提出的问题并不真正相关),因此它实际上不适用于Stackoverflow Q&A模型。
马丁
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.