如果您意识到自己的电子邮件托管服务提供商可以看到您的密码,该怎么办?


31

去年,我们从托管服务提供商处收到了一封电子邮件,内容涉及我们的一个帐户-该帐户已遭到入侵,并曾用来提供相当慷慨的垃圾邮件帮助。

显然,用户已将密码重设为了她的名字的变体(您可能第一次会想到它的名字。)她在一周内迅速被黑了-她的帐户发出了270,000封垃圾邮件,并且很快受阻。

到目前为止,没有什么特别不寻常的。那个会发生。您将密码更改为更安全的方式,教育用户并继续前进。

但是,除了我的一个账户被盗的事实外,令我更加担忧的是。

为了提供帮助,我们的托管服务提供商实际上在以下电子邮件中向我们引用了密码

在此处输入图片说明

我很惊讶 我们将要尽快续签合同,这感觉像是一个大问题。

托管服务提供商能够找出帐户上使用的实际密码有多普遍?

大多数托管服务提供商是否都设有一个帐户滥用部门,该部门比一线代表拥有更多的访问权限(并且可以在必要时查找密码),或者这些人只是没有遵循最佳实践来使他们的任何员工都可以访问用户?密码?我以为密码应该被散列并且无法检索?这是否意味着他们以纯文本形式存储每个人的密码?

托管提供商以这种方式发现帐户密码甚至合法吗?在我看来真是太不可思议了。

在我们考虑更换提供商之前,我想请您放心,这不是常见的做法,而且我们的下一个托管提供商也不太可能以相同的方式进行设置。

期待听到您对此的看法。


4
尽管显然很令人担忧,但对于您所知,这是电话代表的一两次拳打,在票证中记录了新密码(他们永远不要这样做),而另一个代表在票证中看到了该密码。您有权利要求答案,但就目前情况而言,您不知道如何获取密码。
Andrew B

1
我知道用户实际上是通过Web界面设置密码的。他们将其从服务器上的记录中提取出来-办公室中没有人通过电话与他们谈论过(此外,我相信该提供程序无论如何都仅提供电子邮件支持)
Austin“ Danger” Powers

3
我该怎么办?耸耸肩。 您在其他人控制的系统上所做的任何事情对他们都是可见的。 如果您不希望其他人对您的电子邮件系统具有这种可见性,请自己运行并托管它们。您可能不赞成他们使用其所定义的信息进行的操作,但是,如果对他们没有不这样做的合同义务,那么您就签署了合同。
MadHatter支持Monica

19
明文密码的存储是不好的(就像Time to find a new provider坏的一样!)-许多人这样做,但是仍然:不好。是否通过未加密的电子邮件向您发送密码我所有的全部。这表明了对安全性的轻描淡写。奔跑,不要走路,有一些常识的新提供商……
voretaq7

2
我想扩展一下@MadHatter所说的内容:这里很多人都在关注“存储明文密码”的想法。一个简单的事实是,如果我正在运行POP / IMAP服务器,SSH服务器或可以在其中输入密码的任何其他内容,则可以将其配置为在输入密码时记录该密码,而不管是否我将内容存储为散列或明文形式。Google可以看到您的密码,Dropbox可以看到您的密码,而Facebook可以看到您的密码,依此类推。您可以信任您的提供商,也可以自己托管它。
larsk 2013年

Answers:


33

是的,对于ISP和电子邮件服务提供商来说,通常以纯文本或易于恢复为纯文本的格式存储密码。

这样做的原因与PPP(拨号和DSL),RADIUS(拨号,802.1x等)和POP(电子邮件)一起使用的身份验证协议有关

这里的权衡是,如果密码在ISP的数据库中是单向散列的,那么唯一可以使用的身份验证协议就是那些以纯文本形式通过电线传输密码的身份验证协议。但是,如果ISP存储实际密码,则可以使用更安全的身份验证协议。

例如,PPP或RADIUS身份验证可能使用CHAP,它可以保护传输中的身份验证数据,但需要由ISP存储的纯文本密码。与POP3的APOP扩展类似。

此外,ISP提供的所有各种服务都使用不同的协议,使所有这些服务都通过同一数据库进行身份验证的唯一干净方法是将密码保留为纯文本格式。

这并没有解决的问题,谁的ISP的工作人员可以访问数据库中,和它如何妥善固定,虽然。您仍然应该问那些困难的问题。

但是,正如您到目前为止可能已经了解到的那样,ISP的数据库受到破坏几乎是闻所未闻的,而单个用户受到破坏的情况太普遍了。无论哪种方式,您都有风险。

另请参见我是否错误地认为密码永远不可恢复(单向哈希)?在我们的姊妹网站上IT安全性


2
APOP几乎是一个无效协议,MSCHAPv2不需要服务器明确知道密码-我真的不认为如今服务提供商保留明确密码没有太多理由。
Shane Madden

1
@ShaneMadden你是对的;它是CHAP,而不是MSCHAP。是的,这些协议真该死了,但是永远存在的服务提供商可能仍在使用它们提供旧服务。
迈克尔·汉普顿

是的-尽管我想认为更多的旧服务提供商使用的是旧的LDAP,但其中充满的{crypt}是明文密码,而不是明文密码(我过去曾在幕后看过的人采用的方法) )。虽然那可能只是一厢情愿的想法。
Shane Madden

1
强制性密码学注释:“这里的权衡是,如果密码是在ISP的数据库中单向散列的,那么唯一可以使用的身份验证协议就是那些以纯文本形式通过电线传输密码的身份验证协议。但是,如果ISP存储实际的密码,则可以使用更安全的身份验证协议。” 通常是不正确的。这是真的,因为不存在允许使用哈希密码的安全身份验证方案的现有协议。
orlp

1
@nightcracker与要传输的数据量相比也要加密(我希望也加密),少量的身份验证数据并不会真的让您感到那么麻烦
Tobias Kienzler 2013年

12

不幸的是,这对于预算托管人来说是相当普遍的,即使是更大的托管人也并非没有听说过。诸如cpanel之类的东西经常需要您的纯文本密码,才能随便登录各种服务等。

您唯一可以做的就是提前询问是否对密码进行了哈希处理。


28
这是一个非常低预算的主持人...我知道这太真实了。这让我发疯。无论如何,谢谢您的回答。起初我以为这是一个艰巨的任务,但您还是挺身而出的。这样的答案可以帮助该站点达到新的高度。我当时想将其标记为最佳答案,但这是并驾齐驱的。
奥斯丁的“危险”力量

7

他们可能以纯文本形式存储密码,或者使用某种可逆加密。

如您所料,这是非常糟糕的。

不管是由于员工的恶意或过失,还是由于外部方对其系统的危害,滥用纯文本密码都会带来严重的风险-不仅对他们的系统,而且对于其他使用相同密码的系统,都可能造成严重的风险。

负责任的密码存储意味着使用单向哈希函数而不是可逆加密,并在用户输入中添加了(随机数据)以防止使用Rainbow表

如果我不知所措,我会问提供商一些棘手的问题,关于他们如何准确存储密码以及他们的支持代表如何准确地检索密码。这可能并不意味着它们以纯文本形式存储密码,但是也许它们在更改时会将它们记录在某处-这也是巨大的风险。


1
我会问他们一些问题,如果他们说什么有趣的话,请回到这里。我最大的担心是,他们有可能1)阅读我们的任何电子邮件2)阅读我们的电子邮件,查看对个人电子邮件帐户的引用3)如果用户在工作和个人电子邮件中使用相同的密码,则他们的个人电子邮件可能也被妥协。
奥斯丁的“危险”力量

@ Austin''Danger''Powers “有可能1)阅读我们的任何电子邮件 “任何主机都可以做到这一点-毫无例外(假设邮件内容本身未由发件人加密-但这是另一回事)。
orlp

我认为通常只有顶级支持才有可能。如果查看密码是他们的任何支持代表可以做的事情,那么增加不诚实/无聊的员工戳我们的电子邮件的风险。
奥斯丁的“危险”力量

5

所有其他答案都很好,并且具有很好的历史意义。

但是,我们生活在这样一个时代,以纯文本形式存储密码会导致巨大的财务问题,并可能彻底摧毁企业。在NSA吸收所有传递数据的时代,通过不安全的电子邮件以纯文本格式发送密码听起来也很可笑。

您不必接受某些旧协议要求使用纯文本密码的事实。如果我们都停止接受此类服务,则服务提供商可能会对此做些什么,并最终弃用古老的技术。

有人会记住,一旦您想登机飞往另一个国家,您实际上只是从路边停车处走进飞机。从来没有安全。如今,人们意识到需要采取适当的安全措施,并且所有机场都已将其落实到位。

我将切换到另一个电子邮件提供商。在“安全电子邮件提供商”上搜索会产生许多结果。

评论中有一些要点。可能搜索“安全电子邮件提供者”将非常有意义,因为所有电子邮件提供者都会吹嘘它们是安全的。但是,我不能推荐一家特定的公司,而且这也不是一个好主意。如果您找到一家特定的公司,那么首先要对安全性提出棘手的问题将是一件好事。


1
我们上一个网站管理员推荐该提供程序的原因之一是因为它比我们以前的提供程序“更安全”。我很快发现,他们不会允许在密码中,我们的某些特殊字符使用才能够使用,再后来,他们的工作人员不得不进入我们的密码。它们“更安全”的唯一原因是因为它们迫使我们满足某些最小密码长度/复杂性要求-很大。
奥斯丁的“危险”力量

每个人都称其服务“安全”,但事实证明,这并不总是意味着您所认为的含义。该系统应使其成为不可能。几年前,我曾在ISP工作,尽管我可以重设任何客户的电子邮件密码,但我无法看到当前的密码。从理论上讲,这些人可以在我们不了解的情况下阅读我们的电子邮件...我不必依靠信任
奥斯丁的“危险”力量

1
他们是否执行最大长度要求?纯文本密码存储几乎总是金丝雀。
梅尔斯

1
“在“安全电子邮件提供商”上搜索会产生许多结果。” -是的,在这些结果中出现了多少个以纯文本格式存储密码的站点,因为它们认为自己是安全的。根据一些搜索结果,不要为您希望获得安全性的服务选择托管。
罗伯·摩尔

1
@RobM:是的。询问提供商是否相信自己服务是安全的?他们中的100%会说“是”。在网络上搜索这样的通用术语会浪费时间。实际上,解决整个问题似乎是一种相当幼稚的方法:“ 您的系统安全吗?好极了。谢谢您的澄清。在这种情况下,我们将毫不犹豫地订阅您的服务。
奥斯汀“危险”力量

3

我的建议是离开,然后问下一个家伙他们的政策是什么!
如果您感觉很好,您可以告诉旧的医疗服务提供者您为什么要离开。


为了解决另一个答案,彩虹表的时代已经过去了。它们已被高性能的GPU取代,并占用了过多的存储空间(二进制哈希显然不能很好地压缩;而且您也不会以ASCII格式存储它们)。在GPU上(重新)计算哈希值比从磁盘读取哈希值更快。

根据所使用的哈希算法和GPU,一台现代的密码破解计算机有望每秒产生约1亿至10亿个哈希。根据这个,(这是它认为计算机/超级计算机可以做有点过时),这意味着任意6字符密码可以在几秒钟内破解。所有各种算法(MD5,SHA-1,SHA-256,SHA-512,Blowfish等)中的7和8个字符哈希表都将消耗过多的磁盘空间(请注意,您需要将它们存储在SSD上) ,而不是磁石,以提高访问速度),您可以了解为什么使用GPU进行基于字典的攻击会更快地产生密码。

对于那些进入现场的人来说,很不错的文章是《我如何成为 Ars Technica 的密码破解者》


如果您的第二段确实是真的,那就意味着加盐变得毫无用处。这是您的个人观点还是基于事实?
Tobias Kienzler 2013年

@TobiasKienzler的确,使用存储在输出中的值进行加盐处理变得毫无用处,但是使用私有值进行加盐处理仍然可以有效地防御字典攻击。这不是我的个人观点,而是对他人(当前)对密码破解者行为的观察。我也更新了答案。
Nicholas Shanks

2
私人价值是指胡椒吗?无论如何,一个良好的散列函数的所要求的特性是:a)它们是严重以增加所需要的时间耗费时间,或甚至更好b)中它们可以是链施加一个任意大量的时间。因此,尽管我同意过时的哈希/盐是可破解的,但复杂度足够高的哈希/盐却不是。相关信息:密码哈希加盐+胡椒粉还是盐足够?
Tobias Kienzler 2013年

@TobiasKienzler是的,我不确定我对你有多具体:)虽然,显然,bcrypt()这些天应该使用这些站点,但这更多的是破解那些没有使用这些站点的哈希。
Nicholas Shanks 2013年

1
在这种情况下,我同意,但是在安全相关的情况下,坏/过时/弱的哈希(例如MD5)是不可原谅的。
Tobias Kienzler 2013年

1

这发生在我身上!

几年前,当我的托管服务提供商(当时也是我的电子邮件提供商)遭受安全漏洞时,我的身份受到了损害。我很醒,因为我的密码已重设,所以无法检查我的电子邮件。他们控制着我的电子邮件,试图在Amazon和PayPal重置我的密码。您可以猜测接下来会发生什么,对吗?欺诈性信用卡收费!

幸运的是,尽管帐户信息和安全性问题发生了变化(所有时间都在几个小时之内),但我能够快速地找出发生了什么,使我的托管服务提供商通电话,并尽力地验证我的身份。 在对话期间,客户服务代表可以告诉我我的密码历史记录,更改的时间以及更改的内容。 这就是我所需要知道的,我绝对需要更换医疗服务提供者。

没有理由要发生在您,我们的公司!

我对这家公司在安全性方面的彻底性感到怀疑,在与他们打交道的多年中,我在这里和那里都注意到了一些事情。但是我一直坚信自己没什么大不了,或者我误会了。 我没记错,你也不是!

如果我第一次怀疑他们没有认真对待安全时就采取了行动,那整个小噩梦将永远不会发生。想一想有价值的公司帐户被盗后会发生什么?如果他们只发送垃圾邮件,您将轻松下车。当时我工作的公司也正在使用该提供程序,因此我们优先考虑尽快迁移。

相信你的直觉! 不要懒惰地迁移,也不要因为现有设置“工作正常”而承担责任。低安全性监督的最令人讨厌的部分,例如以明文形式存储密码,不正确地配置服务器等,是在技术文化中他们普遍感到无能和/或懒惰,而这是我不希望我公司的任务关键的文化服务合约附近的任何地方。


0

我可以看到另一种解释,其中您的密码实际上是在提供商的服务器上散列的。

当提供者在一天后与您联系时,他的密码更改脚本正在通过GET方法提交数据时,他可能(这是一个推测)将其从服务器日志中删除了。

这听起来比您的提供商的数据库更容易记录,数据库中包含有关何时,何人以及如何更改密码的记录。你知道奥卡姆的剃刀 ...;)

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.