双因素身份验证
你读到的所有内容 与身份识别相关的事实是 请求者知道。 他知道他的电子邮件地址，知道如何访问它（即知道他的电子邮件密码），并且知道安全问题的答案。
“知识”被认为是一种认证因素； 另外两个共同因素是 你有什么，例如，物理设备，以及 你是谁例如指纹或眼睛的视网膜。
在大多数情况下，进行生物识别是不可行的，尤其是当我们谈论Web应用程序的安全性时，因此在双因素身份验证（two-factorauthentication，2FA）中，通常使用第二个属性——“你拥有的东西”。 第二个因素的一个流行变体是物理令牌，例如， :
物理令牌通常用于企业 VPN 和金融服务中的身份验证。 要对服务进行身份验证，您需要将密码和令牌上的代码（经常更改）与 PIN 结合使用。 理论上，要识别攻击者，他必须知道密码、拥有令牌，并且还知道令牌的 PIN。 在密码重置场景中，密码本身显然是未知的，但拥有令牌可以用来证明帐户的所有权。 当然，与任何安全实施一样， ，但肯定会提高进入门槛。
这种方法的主要问题之一是实施成本和后勤工作； 我们正在讨论将物理设备移交给每个客户并教他们新流程。 此外，用户需要随身携带设备，而物理令牌并不总是这样。 另一种选择是使用 SMS 实施第二个身份验证因素，在 2FA 的情况下，可以确认执行重置过程的人员拥有帐户所有者的移动电话。 谷歌是这样做的：
您还需要启用 ，但这意味着下次您重置密码时，您的手机可能会成为身份验证的第二因素。 让我以我的 iPhone 为例来演示这一点，原因很快就会变得清楚：
识别帐户的电子邮件地址后，Google 确定已启用 2FA，我们可以使用验证重置帐户，该验证通过短信发送到帐户所有者的手机：
现在我们需要选择重置过程的开始：
此操作会向注册地址发送一封电子邮件：
此电子邮件包含重置 URL：
访问重置 URL 时，会发送一条短信，网站会要求提供：
这是短信：
在浏览器中输入后，我们回到了经典的密码重置区域：
这听起来可能有点冗长，确实如此，但该表格确认执行重置的人有权访问帐户持有人的电子邮件地址和手机。 但它比仅通过电子邮件重置密码的安全性高九倍。 然而，也存在问题……
该问题与智能手机有关。 下面显示的设备只能证明一种身份验证因素 - 它可以接收短信，但不能接收电子邮件：
不过，该设备可以接收短信 и 接收密码重置电子邮件：
问题是我们认为电子邮件是身份验证的第一个因素，短信（甚至是令牌生成应用程序）是第二个因素，但今天它们被组合在一个设备中。 当然，这意味着如果有人访问您的智能手机，那么所有这些便利都归结为我们再次回到同一频道； 第二个因素“你拥有什么”意味着你也拥有第一个因素。 而且这一切都受到一个四位数 PIN 码的保护……如果手机有 PIN 码的话。 и 他被封锁了。
是的，谷歌的 2FA 功能确实提供了额外的保护，但它并不是万无一失的，而且它当然不依赖于两个完全自治的通道。
通过用户名重置与通过电子邮件地址重置
我应该只允许通过电子邮件地址重置吗？ 或者用户也应该能够按名称重置？ 通过用户名重置的问题是无法通知用户用户名无效， 不透露 其他人可能拥有使用该名称的帐户。 在上一节中，电子邮件重置可确保该电子邮件的合法所有者始终收到反馈，而无需公开披露其在系统中的存在。 仅通过用户名无法完成此操作。
所以简短的答案是：仅限电子邮件。 如果您尝试仅使用用户名进行重置，那么有时用户会想知道发生了什么， или 您将披露帐户的存在。 是的，它只是一个用户名，而不是电子邮件地址，是的，任何人都可以选择任何（可用）用户名，但由于用户倾向于重复使用名称，您仍然很有可能间接泄露帐户所有者。
那么当有人忘记他们的用户名时会发生什么？ 假设用户名不是立即的电子邮件地址（通常是这种情况），则该过程类似于密码重置的开始方式 - 输入电子邮件地址，然后向该地址发送消息，而不透露其存在。 唯一的区别是，这次消息仅包含用户名，而不包含密码重置 URL。 要么这样，要么电子邮件会说该地址没有帐户。
身份验证和电子邮件地址的准确性
重置密码的一个关键方面，甚至可能是 最多的 关键是要验证尝试重置的人的身份。 这确实是该帐户的合法所有者，还是有人试图侵入该帐户或给所有者带来不便？
显然，电子邮件是最方便、最常见的身份验证渠道。 它并不是万无一失的，并且在很多情况下，如果需要高度可信的身份识别，仅仅能够在帐户所有者的地址接收邮件是不够的（这就是使用 2FA 的原因），但它几乎总是起点.重置过程。
如果电子邮件要在提供信心方面发挥作用，那么第一步就是确保电子邮件地址确实正确。 如果有人弄错了符号，那么显然重置将不会开始。 注册时的电子邮件验证过程是验证地址正确性的可靠方法。 我们都见过它的实际应用：当您注册时，您会收到一封电子邮件，其中包含一个可供点击的唯一 URL，这将确认您是该电子邮件帐户的真正所有者。 在该过程完成之前无法登录可确保有动力验证地址。
与安全性的许多其他方面的情况一样，该模型降低了可用性，以换取相对于用户身份的置信度而言提供更高程度的安全性。 对于用户高度重视注册并乐意在流程中添加另一个步骤（付费服务、银行业务等）的网站来说，这可能是可以接受的，但如果用户认为该帐户是“一个- time”，并使用 ，例如，作为对帖子发表评论的一种方式。
识别谁启动了重置过程
显然，恶意使用重置功能是有原因的，攻击者可以通过多种不同的方式使用它。 我们可以使用一个简单的技巧来帮助验证请求的来源（这个技巧 平时 有效）是信函的补充，其中包含重置请求者 IP 地址的建议。 它为接收者提供 一些 用于识别请求来源的信息。
以下是我目前正在 ASafaWeb 中构建的重置功能的示例：
“了解更多”链接将用户带到该网站 ，提供重置请求者的位置和组织等信息：
当然，任何想要隐藏自己身份的人都有很多方法来混淆他们的真实 IP 地址，但这是添加请求者的部分标识的便捷方法，并且 最 在某些情况下，这将使您清楚地了解谁将完成密码重置请求。
电子邮件更改通知
这篇文章贯穿着一个主题——沟通； 尽可能多地告诉帐户所有者该过程的每个步骤发生的情况，而不透露任何可能被恶意使用的内容。 这同样适用于密码实际更改的情况 - 通知店主！
更改密码的原因可能有两个来源：
- 登录后更改密码，因为用户想要新密码
- 由于用户忘记密码而未登录而重置密码
虽然这篇文章主要是关于重置的，但通知第一篇文章可以降低有人在合法所有者不知情的情况下更改密码的风险。 怎么会发生这种事呢？ 一个非常常见的场景是获取合法所有者的密码（重复使用从其他来源泄露的密码、通过键盘记录获得的密码、容易猜测的密码等），然后攻击者决定更改它，从而阻止所有者。 如果没有电子邮件通知，真正的所有者将不会知道密码更改。
当然，在密码重置的情况下，所有者应该已经自己启动了该过程（或绕过了上述身份验证工具），因此更改 不应该 然而，令他惊讶的是，电子邮件确认将是积极的反馈和额外的验证。 此外，它还提供了与上述场景的统一性。
哦，如果还不太明显的话—— 不要通过邮件发送新密码！ 这可能会让一些人发笑，但是 :
日志，日志，日志，还有更多日志
密码重置功能对攻击者很有吸引力：攻击者要么想要访问他人的帐户，要么只是给帐户/系统所有者造成不便。 上面描述的许多做法可以减少滥用的机会，但不能阻止滥用，而且它们当然不会阻止人们尝试以非预期的方式使用某个功能。
对于检测恶意行为，日志记录绝对是无价的实践，我的意思是 非常详细的记录。 捕获失败的登录尝试、重置密码、更改密码（即当用户已经登录时）以及任何可以帮助您了解正在发生的情况的信息； 这在将来会非常有用。 甚至个别修复日志 零件 例如，一个好的重置功能应包括通过网站启动重置（捕获重置请求和使用不正确的用户名或电子邮件的登录尝试）、捕获对重置 URL 上的网站的访问（包括尝试使用不正确的用户名或电子邮件）令牌），然后记录安全问题答案的成功或失败。
当我谈论日志记录时，我的意思不仅是记录页面已加载的事实，而且还收集尽可能多的信息， 如果不是保密的话。 伙计们， 请不要记录密码！ 日志需要注册授权用户的身份（如果他是授权用户，那么他就被授权了） 改变了 现有密码或尝试重置 别人的密码 登录后）、它尝试的任何用户名或电子邮件地址，以及它尝试使用的任何重置令牌。 但也值得记录 IP 地址等内容，如果可能的话，甚至请求标头。 这不仅可以让您重新创建 该 用户（或攻击者）正在尝试做的事情，而且 谁 他就是这样一个。
将责任委托给其他表演者
如果您认为所有这些都代表着巨大的工作量，那么您并不孤单。 事实上，建立一个可靠的账户处理系统并不是一件容易的事。 并不是说它技术上很难，而是它有很多功能。 这不仅仅是重置，还有注册、安全存储密码、处理多次错误登录尝试等等的整个过程。 虽然 除此之外，还有很多工作要做。
如今，有许多第三方供应商很乐意消除这种痛苦，并将其全部抽象为一项托管服务。 这些服务包括 OpenID、OAuth，甚至 Facebook。 有些人 （OpenID确实在Stack Overflow上非常成功），但其他的 .
毫无疑问，像 OpenID 这样的服务解决了很多开发人员的问题，但也可以肯定的是它增加了新的问题。 他们有什么作用吗？ 是的，但很明显，我们没有看到身份验证服务提供商的服务被大量使用。 银行、航空公司、甚至商店都实施自己的身份验证机制，这显然是有充分理由的。
恶意重置
上述每个示例的一个重要方面是旧密码仅被视为无用 确认账户所有者身份后。 这很重要，因为如果可以重置帐户 对 身份检查，这将为各种恶意活动提供机会。
举个例子：有人在拍卖网站上竞价，在竞价过程即将结束时，他们通过启动重置过程来阻止竞争对手，从而将他们从竞价中删除。 显然，如果设计不当的复位功能可能被误用，可能会导致严重的负面结果。 值得注意的是，阻止无效登录尝试的帐户是类似的情况，但这是另一篇文章的主题。
正如我上面所说，如果您让匿名用户仅通过知道他们的电子邮件地址即可重置任何帐户的密码，那么这就是拒绝服务攻击的现成情况。 可能不是那个 ，我们曾经谈论过，但是没有比考虑不周的密码重置功能更快地阻止对帐户的访问的方法了。
最薄弱的环节
从保护单个帐户的角度来看，上面写的所有内容都很棒，但您始终需要牢记您所保护的帐户周围的生态系统。 让我举一个例子：
ASafaWeb 托管在 AppHarbor 提供的一项令人惊叹的服务上。 重置托管账户的流程如下：
阶段1：
阶段2：
阶段3：
阶段4：
阅读完前面的所有信息后，已经很容易理解在理想世界中我们会以稍微不同的方式实现哪些方面。 然而，我在这里想说的是，如果我在 AppHarbor 上发布像 ASafaWeb 这样的网站，然后提出很好的安全问题和答案，添加第二个身份验证因素，并按照规则执行其他所有操作，这不会改变事实上，整个过程中最薄弱的环节将能够打破这一切。 如果有人使用我的信息在 AppHarbor 中成功进行身份验证，那么他将能够将任何 ASafaWeb 帐户的密码更改为他需要的密码！
关键是，应全面考虑安全实施的强度：应在系统中的每个入口点对威胁进行建模，即使它是登录 AppHarbor 等肤浅的过程。 这应该让我清楚地知道我需要在 ASafaWeb 密码重置过程中付出多少努力。
把它们放在一起
这篇文章包含很多信息，所以我想将其集中在一个简单的视觉方案中：
请记住，您应该对每一项进行最详细的记录。 就是这样，很简单！
结果
我的帖子似乎很全面，但是我还有很多其他材料 可能 包含在其中，但为了简洁起见，决定不使用它：救援电子邮件地址的作用、您无法访问与您的帐户关联的电子邮件的情况（例如，您辞职了）等等。 正如我前面所说，重置功能并没有那么复杂，只是有很多不同的观点。
尽管重置并不那么复杂，但它经常被错误地执行。 上面我们看到了几个例子，其中实现 может 导致出现问题的情况还有很多，错误重置的情况 真 造成了问题。 最近事实证明 。 这是一个严重的负面结果！
所以要小心你的重置功能， 在设计某个功能时，不要摘下你的黑帽子，因为很有可能其他人会戴上它！
由于宣传
维迪斯娜 提供便宜的 每日付费，每台服务器都连接到 500 Mbps 的互联网通道，并免费免受 DDoS 攻击！
来源： habr.com
