什么更安全?我是否应该向用户发送包含过期URL的电子邮件以重置密码,还是应该通过电子邮件发送新生成的密码?

时间:2010-02-16 23:16:19

标签: security passwords reset-password

我想知道当用户忘记密码时会有更安全的选择

  • 将随机生成的新密码发送到电子邮件地址(我的数据库中的所有电子邮件地址都已确认可用)。

或者

  • 发送一封电子邮件,其中的链接会在用户可以重置密码的特定时间范围内过期。

除了后者使用额外表格之外,您认为更安全/更好的做法是什么?

14 个答案:

答案 0 :(得分:21)

如果您发送包含密码的电子邮件,则表示:

  • 密码将通过某些网络(未加密)并且可以“看到”
  • 密码将保留在用户的邮箱中
    • 可以被黑客攻击
    • 任何有权访问计算机的人都可以看一下

因此,在电子邮件中发送密码似乎并不安全......


作为用户,我觉得我的密码“更安全”,包含某种令牌的链接会在一段时间后过期。

在一段时间后过期”部分很重要,顺便说一句:它确保如果有人在一段时间后点击链接(例如,有人访问用户的邮箱) ,该链接不会用于生成新密码。


当然,这意味着我不能只是“在我的邮箱中搜索”来找到密码 - 但我总是可以要求一个新的我再次忘记它^^ < / p>

答案 1 :(得分:10)

这里的其他答案让人感到困惑。他们完全一样。两者都允许访问用户的帐户,两者都以纯文本形式发送,并且两者都是常用的。选择你喜欢的。

使用链接/密码后立即更改密码,并在24-72小时后使链接/密码过期。

答案 2 :(得分:8)

  

发送一封电子邮件,其中的链接会在特定时间范围内过期,用户可以在该时间范围内重置密码。

那个,当然。

电子邮件始终处于清晰状态(可能不是您的站点连接),并且可以触摸更多计算机。将密码保留在电子邮件之外。临时重置令牌还意味着如果邮箱稍后被黑客入侵,则该令牌将不再使用。

  

除了后者使用额外的表格之外,

它没有。您可以生成加密令牌,授权特定用户在特定时间范围内重置密码;无需额外数据。

使用基于HMAC的消息验证代码(花式散列)的示例:

details= user_id+' '+token_expiry_timestamp
mac= hmac_sha2(server_secret, details)
token= details+' '+mac

然后将token作为邮件中可点击URL的一部分发送给用户。当您收到回拨后,请计算出mac应该为该用户提供的内容以及服务器端密码的时间,并针对传入的mac进行检查。如果匹配,则必须是您之前签署的密码请求。

user_id, token_expiry_timestamp, mac= token split on ' '
details= user_id+' '+token_expiry_timestamp
if hmac_sha2(server_secret, details)!=mac
    complain
else if token_expiry_timestamp<now
    complain
else
    allow password for user_id to be changed

这不需要任何状态,但您应该使用较短的过期时间,因为如果您不记录使用情况,则可以多次使用令牌。

答案 3 :(得分:7)

人们似乎忽略的一个区别是 - 以网络应用程序为例 - 密码重置选项通常对访问网站的任何人开放,并且知道他们想要重置密码的帐户的用户名/登录名对

通过在用户必须点击的电子邮件中发送链接以便能够重置其密码,您可以避免让用户意外或恶意地重置其他人的密码 - 所有这一切都会发生,因为他们收到的电子邮件会以,“如果您没有要求重置密码,请忽略此电子邮件。”

即使它本身并不存在安全风险,重置密码而不进行确认可能是一个很大的烦恼。

答案 4 :(得分:2)

显然后者更安全。电子邮件就像一张明信片。几乎任何人都可以阅读它想要的人。此外,更改密码后,请发送电子邮件以关闭循环。

答案 5 :(得分:1)

只要URL没有要求输入密码或其他密码,它仍然优于随机发送的密码,但仅仅因为它不会在收件箱中以明文形式保留密码。

换句话说,该链接减少了机会之窗。

答案 6 :(得分:1)

我一直都喜欢设置哈希码并给它们一个链接。

之后向用户发送电子邮件,让他们知道他们已经请求了密码恢复链接,并且在他们设置了一个告诉他们密码被更改之后,通常是一个很好的礼节,以防万一有违规行为。

如果用户不打算这样做,用户会很快回复一封电子邮件,说明他们的密码已被更改。

不幸的是,没有真正的“安全”方式。安全问题引脚可以帮助但永远不会真正安全。

答案 7 :(得分:1)

  1. 向他们发送一封随机,一次性使用的电子邮件, 密码。

  2. 强制他们改变 密码首次到达时。

  3. 通知他们他们改变了他们的 密码

  4. 发送随机密码与发送链接的风险一样大。即任何人都可以先收到电子邮件,并在第一时间以用户身份登录。

    通过强制进行更改,无论谁先获得密码都无法再次到达那里。

    通知用户此更改会告诉他们密码已更改,这可能发生在攻击者实际登录并更改通知电子邮件之前。

    因此,如果有人首先访问该网站,则原始密码不再有效,原始发送给该用户的电子邮件将不再有效。此外,他们将收到密码更改的通知。

    这使他们有机会在系统管理员出现时通知他们,并发现他们无法登录他们的帐户。

    这些都不会阻止一个人拦截电子邮件并获得一些访问权限的能力,但至少它让原始的,既得的用户知道某些事情是不对的。

答案 8 :(得分:1)

有些人表示两者都是等价的 - 出于以下原因,情况并非如此:

1)使用重置链接,如果攻击者可以访问电子邮件并因此使用重置链接更改密码,即使攻击者删除了实际的重置电子邮件和通知,他们也会提醒用户。如果用户请求重置并且攻击者看到随机密码(甚至更晚),则使用邮件密码,然后攻击者可以访问您网站上的用户帐户而无需提醒用户。

2)此外,如果您邮寄密码,用户可能会想要在其他网站上重复使用密码,并且有权访问电子邮件的攻击者可以访问其他网站,即使其他网站也不容易通过帐户接管帐户回收

通过电子邮件和重置链接发送随机密码,如果攻击者控制用户的电子邮件,则他们可以访问用户的帐户。在这种情况下,您可以做什么,取决于您拥有的用户手柄数量 - 例如,如果您有主要和备用电子邮件地址,那么您应该在请求和使用重置时向两个电子邮件帐户发送通知,或者有电话,你可以发送电子邮件等文本。你可以监控使用情况,但这更难。

其他几个问题:

链接可以多次使用吗?除了过期并具有不可预测的值(附加MAC以便可以在没有服务器状态的情况下进行验证),如果尝试多次重置帐户密码,您可能希望内部警报响起(注册成功/失败,远程IP地址,时间戳等)并在首先中止并将帐户置于某种非活动状态。

最好看看有多少滥用行为,看看您是否需要更多防御机制来防止通过您的帐户恢复流程进行帐户接管(取决于帐户的价值)。

在这种情况下,最重要的是要及时了解电子邮件地址和其他联系信息(如果可以的话,电子邮件地址会被回收)以及如何更新/添加电子邮件地址或其他此类信息,以及通知。

始终确保您的通知(文字,链接,目标网页)不会让网络钓鱼者轻松完成。

除非您拥有大型网站,否则其中一些问题当然可能不太相关。

答案 9 :(得分:0)

发送链接,以便日后重置密码。这迫使他们在某种程度上确认了他们的帐户,他们正在重置密码。如果您在不发送电子邮件的情况下重置密码,则任何人都可以登录该站点并重置其他人的密码。这会产生拒绝服务类型漏洞。

答案 10 :(得分:0)

虽然我可能会重复一些答案,但我觉得有必要回应,因为我们最近遇到了一些有问题的密码恢复工具问题。我的一个同事的个人帐户遭到入侵,这使得我们的谷歌托管域应用程序遭到入侵。由于未删除的明文密码和愚蠢的密码恢复问题是可谷歌的,其他帐户也受到了损害。

我只想说,我强烈支持在 4小时之后过期的电子邮件链接。我收到链接后,我在那里坐了4个小时登录我们的帐户,确保它仍然没有妥协。 24-48小时将是太长时间,不得不这样做。 4个小时太长了。用户在下次登录时需要更改的随机生成的密码是第二好的,但它完全取决于用户实际登录。密码永久更改,而如果用户对链接不做任何操作,则密码不会被重置。

对于想要破坏您的系统的专门人员,没有完美的解决方案。有比其他更好的解决方案。

答案 11 :(得分:0)

扩展bobince的解决方案......此处用户需要在密码重置页面重新输入userId和token。

请求重置密码页

urserId = Input userId
token = Randomly generated token (or one time password)
tokenExpire = Decide token expiry date/time
Store in DB tokenExpiry for this urserId
urlToken= MD5 hash value of (urserId + token + tokenExpire)
pwdRestURL = server pwd reset url + "?urlToken=" + urlToken

Send above generated URL and make sure you do not 
    include either of userId or token in email

Display token to user (This is to be used on password reset page)

在密码重设页面上(使用上面的pwdRestURL网址)

urlToken = Token from URL request
userId = Input userId
token = Input token
tokenExpiry = tokenExpiry from DB for this user
resetToken = MD5 hash value of (urserId + token + tokenExpire)
IF
    resetToken == urlToken 
    AND tokenExpiry for user is valid
THEN
    Clear tokenExpiry
    Allow user to change password
ELSE
    Display Error
END IF

上述方法的优点:

  • 即使电子邮件是暴露的一部分 网络,没有人可以重置密码 不知道userId和令牌。
  • 令牌有一个到期时间
  • 没有明确的测试个人信息 通过电子邮件转发

答案 12 :(得分:-1)

除了ceeyajoz之外的每个人都在使用有缺陷的逻辑。很难考虑安全性。

两种情况都使用纯文本的电子邮件。当电子邮件被黑客入侵时,两者都同样不安全。

如果URL过期,因为电子邮件被黑客攻击无关紧要,黑客只能请求另一个密码重置URL。如果临时密码已更改,则黑客可以请求新密码。无论哪种方式,你都被搞砸了。

所以我说只需发送密码,这样就可以减少用户选择新密码的步骤。

修改的 当我说“发送密码”时,它是在你发送新随机密码的OP的上下文中。

答案 13 :(得分:-1)

我同意遗嘱的流程。

但是,如果您只选择您提供的选项,虽然两个选项基本相同,因为您通过电子邮件发送信息,我认为后者是一种更常用的方法。

如果黑客要请求新密码,则用户的旧密码将不再有效。至少使用后一个选项,它实际上并没有改变任何用户细节。