我最近忘记了我们有线电视提供商在线帐户的密码,却发现他们是通过电子邮件中的纯文本发送给我们的。我很快向客户支持发送了一封电子邮件,询问他们是否将密码以纯文本形式存储在数据库中。实际上,我从他们的一位软件工程师那里得到了快速回复,他说由于“应用程序的设计”,有必要以可恢复的格式对密码进行哈希处理。
我没有发回电子邮件询问他们是否使用了盐,但总的来说,我认为他们在密码安全和恢复方面坚持最低公分母。
我在这里错了吗?如果他们使用强加密方法,这完全可以接受吗?
我最近忘记了我们有线电视提供商在线帐户的密码,却发现他们是通过电子邮件中的纯文本发送给我们的。我很快向客户支持发送了一封电子邮件,询问他们是否将密码以纯文本形式存储在数据库中。实际上,我从他们的一位软件工程师那里得到了快速回复,他说由于“应用程序的设计”,有必要以可恢复的格式对密码进行哈希处理。
我没有发回电子邮件询问他们是否使用了盐,但总的来说,我认为他们在密码安全和恢复方面坚持最低公分母。
我在这里错了吗?如果他们使用强加密方法,这完全可以接受吗?
对于 ISP 来说,他们很可能以纯文本或使用可逆加密存储您的密码。这种可逆加密不是答案声称的散列。
ISP 倾向于不使用单向哈希,因为许多旧协议使用密码作为质询-响应摘要身份验证的一部分。
最值得注意的是APOP,它是旧邮局协议的扩展。在普通 POP 中,用户名和密码以明文形式传输,这显然很糟糕。所以人们想到了一个防止嗅探和重放攻击的扩展:服务器发送一个唯一的标识符(出于某种奇怪的原因,它在规范中被称为时间戳,尽管它更多)。客户端在计算 MD5 哈希之前连接此标识符和密码。服务器需要做同样的计算,因此它需要清除密码。该协议已过时;应该使用 POP over SSL。但它仍然被普遍使用。
此外,ISP 通常提供多种服务,让它们都使用中央身份验证机制是一个巨大的挑战。因此,密码经常被复制到这些服务器上。由于出于可靠性原因,这种复制必须在任何时候都可以重现,因此通常存储明文密码。如果无法进行中央身份验证,则最好将不同的加密格式存储在复制源而不是普通密码。
将这些密码提供给客户和第一级支持人员显然是非常糟糕的做法。用普通的电子邮件发送它们会使情况变得更糟。
有许多协议要求密码以明文(或加密但不散列)存储,例如 HTTP Digest 身份验证,因此有正当理由以可恢复格式存储密码。做得对,这是可以接受的。在暴露的密码存储(和加密密钥)的情况下,即使经过哈希处理,大多数密码也可以很便宜地恢复,因此差异不是很大。
但是,你对他们行为的描述听起来并不令人信服——这可能是合法的,但我不会打赌。
但是,作为用户,您永远不应该相信您的密码不是以明文形式存储的(例如,查看您帐户的管理员可以看到),或者该服务实际上设法保证密码安全。这意味着在站点之间不共享密码的正常预防措施以及密码很难通过看一眼就记住。
ISP 与其他所有人一样,容易受到内部攻击、外部妥协和社会工程的攻击,因此您描述的做法非常糟糕。最重要的是,他们不应该向“你”发送你的密码——这对社会工程来说太容易了。他们应该重置您的密码并向您发送令牌以登录并创建一个新密码。
除此之外,尽管我们努力鼓励人们不要重复使用密码,但任何在线存储密码都会使用户面临风险。
正如其他人所指出的,有些旧协议需要纯文本,例如 APOP 和 HTTP Digest Authn,它们可能解释了这些旧的内部流程。微软的一些旧系统也存在同样的问题。但是这些都是糟糕的协议,应该被淘汰,正是因为这些原因。
正确散列合理的密码确实可以防止破解。
请参阅如何安全地散列密码?对于如何做到这一点(以及如何不办了!)