我想知道当用户忘记密码时更安全的选择是什么
- 将随机生成的新密码发送到电子邮件地址(我的数据库中的所有电子邮件地址均已确认有效)。
或者
- 发送包含在特定时间范围内过期的链接的电子邮件,用户可以在其中重置密码。
除了后者使用额外的表格之外,您认为更安全/更好的做法是什么?
我想知道当用户忘记密码时更安全的选择是什么
或者
除了后者使用额外的表格之外,您认为更安全/更好的做法是什么?
如果您发送包含密码的电子邮件,则意味着:
所以,在电子邮件中发送密码似乎并不安全......
作为用户,我会觉得我的密码“更安全”,链接包含某种令牌并在一段时间后过期。
“一段时间后过期”部分很重要,顺便说一句:它确保如果有人在一段时间后点击链接(例如,访问用户邮箱的人),该链接将不会用于生成新密码。
当然,这意味着我不能只“在我的邮箱中搜索”来找到密码——但我总是可以要求一个新的,我又忘记了^^
对这里的其他答案感到困惑。它们完全一样。两者都可以访问用户的帐户,都以纯文本形式发送,并且都是常用的。选择你喜欢的。
一旦他们使用链接/密码,立即强制更改密码,并让链接/密码在 24-72 小时后过期。
发送包含在特定时间范围内过期的链接的电子邮件,用户可以在其中重置密码。
那个,绝对的。
电子邮件始终清晰(可能您的站点连接可能不清晰),并且可以接触更多机器。将密码保存在电子邮件之外。临时重置令牌还意味着,如果邮箱稍后被黑客入侵,该令牌将不再有用。
除了后者使用额外的桌子之外,
它不必。您可以生成加密令牌,授权特定用户在特定时间范围内重置密码;不需要额外的数据。
使用基于 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
这不需要状态,但您应该使用较短的过期时间,因为如果您不记录使用情况,令牌可能会被多次使用。
人们似乎忽略的一个区别是 - 以 Web 应用程序为例 - 密码重置选项通常对访问网站并知道他们想要重置密码的帐户的用户名/登录名的任何人开放。
通过在电子邮件中发送用户必须单击才能重置密码的链接,您可以避免让用户意外或恶意重置其他人的密码 - 所发生的只是他们收到一封结尾为“如果您没有要求重置密码,请忽略此电子邮件。”
即使它本身不是安全风险,在没有确认的情况下重置密码也可能是一个主要的烦恼。
显然后者更安全。电子邮件就像一张明信片。几乎任何人都可以阅读它。此外,一旦更改密码,请发送电子邮件以关闭循环。
只要 URL 不要求输入密码或类似的东西,它仍然比随机发送的密码更好,但这只是因为它不会将密码以纯文本形式留在收件箱中。
换句话说,链接减少了机会之窗。
我一直很喜欢设置哈希码并给他们一个链接。
之后向用户发送一封电子邮件,让他们知道他们请求了一个密码恢复链接,并且在他们设置了一个告诉他们他们的密码已更改之后,这通常是一种很好的礼貌,以防出现违规行为。
如果用户无意更改密码,用户会很快对一封电子邮件做出反应。
不幸的是,没有真正的“安全”方式。安全问题 pin 可以提供帮助,但永远不会真正安全。
向他们发送一封带有随机、一次性使用密码的电子邮件。
强制他们在他们第一次到达时更改密码。
通知他们他们更改了密码。
发送随机密码与发送链接的风险一样大。即任何人都可以先收到电子邮件并在第一时间以用户身份登录。
通过强制更改,如果没有设置密码,谁先得到他们的人就无法再次到达那里。
通知用户更改告诉他们密码已更改,这可能发生在攻击者实际登录并更改通知电子邮件之前。
因此,如果有人首先访问该站点,则发送给用户的原始电子邮件将不再有效,因为原始密码不再有效。此外,他们将收到有关密码更改的通知。
这为他们提供了一个机会,当他们出现并发现他们无法登录到他们的帐户时通知系统管理员。
这些都不能阻止一个人拦截电子邮件并获得某些访问权限的能力,但至少它让原始的、既得的用户知道出了问题。
有些人说两者是等价的——这不是真的,原因如下:
1)如果攻击者可以访问电子邮件并因此使用重置链接更改密码,则使用重置链接,即使攻击者删除了实际的重置电子邮件和通知,他们也会提醒用户。如果用户请求重置并且攻击者看到随机密码(甚至更晚),则使用邮件密码,那么攻击者可以访问您网站上的用户帐户而无需提醒用户。
2) 此外,如果您邮寄密码,用户可能会想在其他网站上重复使用密码,并且可以访问电子邮件的攻击者可以访问其他网站,即使其他网站不容易通过帐户恢复来接管帐户。
通过电子邮件中发送的随机密码和重置链接,如果攻击者控制了用户的电子邮件,他们就可以访问用户的帐户。在这种情况下您可以做什么,取决于您拥有的用户的句柄数量 - 例如,如果您有他们的主要和备用电子邮件地址,那么您应该在请求和使用重置时向这两个电子邮件帐户发送通知,或者如果他们有电话,除了电子邮件之外,您还可以向他们发送文本等。您可以监控使用情况,但这更难。
其他几个问题:
链接可以多次使用吗?除了过期和具有不可预测的值(带有附加的 MAC,因此可以在没有服务器状态的情况下对其进行验证)之外,如果多次尝试在帐户上重置密码(注册成功/失败,远程 IP 地址、时间戳等),然后首先中止并将帐户置于某种非活动状态。
看看发生了多少滥用行为以了解您是否需要更多的防御机制来防止通过您的帐户恢复流程(取决于帐户的价值)来防止帐户被接管,这将是一个好主意。
在这种情况下,如果可以的话,保持最新的电子邮件地址和其他联系信息也非常重要(电子邮件地址在不使用时会被回收)以及如何更新/添加电子邮件地址或其他此类信息和通知。
与往常一样,请确保您的通知(文本、链接、登录页面)不会让网络钓鱼者轻松上手。
除非您有一个大型站点,否则其中一些问题当然可能不是很相关。
从 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 URL)
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
.
上述方法的优点:
虽然我可能会重复一些答案,但我觉得有必要做出回应,因为我们最近遇到了一些与错误密码恢复工具有关的问题。我同事的一个个人帐户被盗用,这使得我们的谷歌托管域应用程序被盗用。由于未删除的明文密码和可通过谷歌搜索的愚蠢密码恢复问题,其他帐户也受到了损害。
可以这么说,我是4 小时后过期的电子邮件链接的坚定拥护者。在收到链接后,我坐了 4 个小时登录到我们的一个帐户,确保它仍然没有受到损害。24-48 小时太长了,不能这样做。4小时太长了。用户下次登录时需要更改的随机生成的密码是次优的,但它完全取决于实际登录的用户。密码是永久更改的,而如果用户对链接不做任何操作,密码将不会被重置。
对于想要破坏您的系统的专职人员,没有完美的解决方案。有比其他更好的解决方案。
向他们发送链接,以便他们以后可以重置密码。这迫使他们在某种程度上确认他们正在为其重置密码的实际帐户。如果您在不发送电子邮件的情况下重置密码,任何人都可以登录该站点并重置其他任何人的密码。这会产生拒绝服务类型的漏洞。
除了 ceeyajoz 之外的每个人都在使用有缺陷的逻辑。很难考虑安全性。
这两种情况都使用纯文本的电子邮件。当电子邮件被黑客入侵时,两者同样不安全。
URL 是否过期无关紧要,因为电子邮件被黑客入侵,黑客只需请求另一个密码重置 URL。如果临时密码已更改,黑客可以请求一个新密码。无论哪种方式,你都被搞砸了。
所以我说只是发送密码,这样用户选择一个新密码就少了一步。
编辑 当我说“发送密码”时,它是在 OP 的上下文中发送一个新的随机密码。
我同意will的流程。
但是,如果您只在您提供的选项之间进行选择,尽管这两个选项在您通过电子邮件发送信息方面基本相同,但我认为后者是一种更常见的方法。
如果黑客要请求新密码,则用户的旧密码将不再有效。至少对于后一个选项,它实际上并没有更改任何用户详细信息。