电子邮件明文密码的密码管理

信息安全 密码 哈希 账户安全
2021-08-30 02:13:24

如果一个网站在您使用“忘记密码”功能时以明文形式发送密码,是否有可能对密码进行哈希处理?如果您再次重置它,它确实会生成一个不同的密码,但它总是以明文形式通过电子邮件发送。

是否可以重置用户的密码,继续以明文形式通过电子邮件发送,然后对其进行哈希处理?如果是,这是否被认为符合良好的安全实践?

使用新创建的密码登录后,该网站不要求您设置新密码。

4个回答

“如果网站在您使用“忘记密码”功能时通过电子邮件发送明文密码,是否有可能对密码进行哈希处理?

当然是。该站点可能(实际上应该)以散列形式存储密码,并在生成纯文本时将其发送给您,然后将其从内存中删除。后者是良好的安全实践;以明文形式发送实际密码......不是那么多。

是否可以重置用户密码,继续以明文形式通过电子邮件发送,然后对其进行哈希处理?如果是,这是否被认为符合良好的安全实践?

是的,这确实良好安全实践的开始。但是现在我们有了一个安全令牌,它已发送给不知道有多少系统,它可能存在于无数的明文备份中,甚至可能对任何拥有您的电子邮件密码的人都可用;破解邮箱,访问所有网站。

所以,我们...

还有一件事我忘了添加....该网站不要求您在使用新创建的密码登录后设置新密码。

...确切地。所以好的安全做法是发送一个随机令牌(或 URL,这是同一个概念),仅在短时间内有效,而不是实际密码,以明文形式发送;并使用它来创建用户选择的新密码。

一旦发送和接收并确认密码后不更改密码绝对一种非常糟糕的安全做法,因为它会留下一个很好的密码。

如果用户选择了新密码,它可以在网站上保持散列,并且只会从用户的内存传输到他们的计算机,然后通过 HTTPS 传输到服务器 - 尽可能安全的电路。

一些问题(与问题本身无关)

代币存储

有人可能会担心如何识别令牌是有效的。您不必将令牌存储在任何地方;您可以让令牌具有自我描述性。当然,这需要它包含足够的信息,以至于输入它可能会很尴尬。

示例生成:

date = toBase62(timestamp/60); // 32 bits of timestamp, divided by 60, are about 26 bits, and become five characters. You can use a timestamp starting 2021-01-01 to get smaller numbers that fit in even less bits.
hash = md5(concat(secret,':',date,':',user); // 32 hex digits

token = concat(user,':',date,':',substr(hash, 8))

令牌现在可能是lserni:a7XzQ:baadf00d. 收到后,我可以检查日期是否在最后 X 小时内(否则无效),在此之前我检查我的秘密加日期和用户的 MD5 是否以“baadf00d”结尾。需要 2^32 次尝试的暴力破解,因此它并不完全可行。

拒绝服务或骚扰

如果我知道某人的帐户,我可以触发重复的密码重置。他们不会通过,但用户会收到来自服务器的大量电子邮件,这给双方带来了不便。另外,如果我想阻止他们重置密码,这很有效——因为他们会收到数百封电子邮件,而只有一封是他们要求的。

为了阻止重复发送,不要只对外发电子邮件设置速率限制,因为这会允许某人将用户锁定在密码重置过程之外。或者如果你这样做了,那么你必须接受任何有效的令牌,而不仅仅是最后一个(如果你不做存储,这是一个自动的好处)。即便如此,您也有可能知道用户密码的人可能会:

  • 发送密码重置请求,用户将忽略该请求
  • 以用户身份登录并手动更改密码
  • 现在用户不能在 24 小时内重置密码!

在这种情况下,诀窍是在每次有人使用正确密码登录时重置“无电子邮件”安全锁定时间。这可能是与用户帐户关联的时间标志。此外,在 X 次无电子邮件密码更改后,必须拒绝进一步的密码更改,除非通过电子邮件链接执行。

(所有这一切都假设攻击者无法更改与帐户关联的电子邮件地址,否则他们只能登录、更改电子邮件地址、更改密码并锁定合法所有者。用户可以选择加入安全措施这只允许通过向当前电子邮件发送辅助令牌来更改电子邮件,如果他们无法访问电子邮件,这会使他们面临一些麻烦——这就是为什么某些服务提供辅助“恢复”电子邮件的原因)。

绝对地。这对于初始密码很常见。您设置了一个新帐户,系统生成一个密码,将其通过电子邮件发送给用户,但它已正确散列并存储在服务器端。例如,Microsoft 365 就是这样做的。这通常意味着通过电子邮件发送的密码会在您使用后触发重置。

如果密码由用户设置可能会更好,但这并不总是可能的。

允许通过电子邮件发送的密码在使用后保留不是“最佳实践”。

一种好的做法是将用户重定向到可以设置新密码的页面。可以通过电子邮件发送指向密码重置页面的链接。

以明文形式发送密码是不安全的。如果发生这种情况,则页面应要求在初始登录后对其进行更改。

有些网站以明文形式向您发送密码 - 这意味着它不会在数据库中保存散列:https ://plaintextoffenders.com/

我认为主要的不安全感来自于此:

使用新创建的密码登录后,该网站不要求您设置新密码。

在最佳情况下,流程将是这样的:

  1. 您要求重设密码
  2. 带有令牌的新密码URL 将发送到您的电子邮件
  3. 密码或 URL 的有效期为 30 分钟
  4. 输入新密码或单击带有令牌的 URL 后,系统会提示您设置所需密码

注意第 3 步需要有一个生命周期吗?这就是对抗受损电子邮件的方法。攻击者可以像输入给定密码一样轻松地单击带有令牌的 URL;反正都是明文!

鉴于#4 似乎没有实现,那么我假设#3 也没有。我认为他们的密码重置系统不安全。


密码是否在服务器端存储为哈希是一个完全不同的讨论。在这个时候,我会假设答案是肯定的。

如果电子邮件只是以明文形式告诉您旧密码,那么这将表明明文密码存储或可逆加密机制。