因此，您正在构建一个应用程序，最后进入了需要担心用户身份验证的阶段。你在想办法从哪里开始？或者你已经有了一个解决方案，现在想知道它是否足够。无论如何，正确地实现身份验证很容易成为一项巨大而危险的任务。断开的身份验证一直列在十大Web应用程序安全风险列表中。与身份验证和会话管理相关的应用程序功能通常执行不正确，使得攻击者能够泄露密码、密钥或会话令牌，或者利用其他实现缺陷暂时或永久地假定其他用户的身份。人们很容易低估构建安全且用户友好的身份验证系统所需的所有工作。让我们看看一些通常被忽略的特性，以及一些可能在身份解决方案中丢失的攻击面。密码安全当有人说"身份验证"时，你首先想到的是什么？对很多人来说，归结起来就是：验证用户名和密码。在构建身份解决方案时，验证登录凭据只是冰山一角，但这是一个很好的开始。当用户注册您的应用程序时，他们通常必须创建一些凭据集，以便在需要再次登录时使用这些凭据来标识自己。这意味着您的应用程序必须在创建时将这些凭据安全地存储在数据库中的某个位置。当用户返回并尝试再次登录时，您需要对照数据库中的凭据检查他们提供的凭据。很简单，对吧？别这么快。如果做得不正确，这个简单的任务可能会引起大量的蠕虫。以下是一些需要考虑的事项：您将如何存储和保护凭据？密码创建有什么要求吗？长度？复杂性？如果有人忘记了他们的登录凭据，你会怎么做？让我们在研究密码安全在身份解决方案中所起的作用的同时，探讨其中的一些问题。散列密码在保护存储的凭据时，哈希是必不可少的。散列是一种数据的单向转换，使用一种基于称为哈希函数的数学计算的算法来完成。根据OWASP，哈希函数必须具有以下属性：计算散列值既简单又实用，但"如果只知道散列值，就很难或不可能重新生成原始输入。"很难创建与特定期望输出匹配的初始输入。那么这与密码安全有什么关系呢？当用户注册您的应用程序时，您需要以最小化风险的方式将其用户名和密码存储在数据库中。如果你的用户数据库被盗，你不想让攻击者访问用户名和明文密码！散列你的密码是一种减少这种风险的方法。当他们输入密码时，你通过一个安全的哈希函数发送密码，并用他们的用户名将输出存储在数据库中。然后，当用户再次登录时，您将散列他们键入的密码，并将其与存储在数据库中的散列密码进行比较。如果他们匹配，那么密码是正确的！这种方法的一个缺点是，如果persona和personb具有相同的密码，那么它们的哈希密码也将相同。因此，如果攻击者获得数据库并手动破解用户a的密码，那么他们也知道用户B的密码。这是密码的闪光点。salt是在散列之前可以添加到密码输入中的附加数据。在散列之前向每个密码添加一个随机salt可以确保persona和personb具有唯一的哈希，尽管它们的明文密码是相同的。如果您想了解更多关于哈希和salt的知识，请查看这个优秀的系列：哈希密码单向安全之路。密码重置流程现在，您的密码被哈希和加盐，让我们看看如何处理密码恢复。用户忘记登录凭据是相当常见的。这是一个很好的例子，您的身份验证解决方案需要在出色的用户体验和安全性之间划清界限。下面是一个很好的密码恢复过程：用户点击"忘记密码"他们输入他们的电子邮件地址认证服务器向电子邮件地址发送一次性密码（OTP）用户检查电子邮件并单击链接或在网站上输入OTP应用程序检查OTP是否匹配，如果匹配，则允许用户重置密码一旦你有了流程，你还必须考虑如何创建OTP。链接什么时候到期？你有没有确定代币是随机的，足够长，以防被猜中？实现这一点可能是棘手和耗时的，但有了一个免费的Auth0帐户，您有一个内置的密码恢复选项，您的目的是不费吹灰之力！密码安全攻击表面这甚至比不上强制和维护安全密码所需的详尽列表。但是，即使只有这两点，散列和密码恢复，如果实现不正确或根本没有实现，也会打开几个攻击面。让我们看看其中的几个。凭证填充攻击-如果您的用户数据库被破坏，并且凭证以明文形式存储或使用弱哈希算法存储，攻击者现在不仅可以轻松访问您的所有用户帐户，而且还可以使用您的数据库运行凭证填充攻击。因为密码重用非常普遍，所以很有可能其中一些凭证在其他网站上是活跃的。攻击者将把这些窃取的用户凭证卖给试图通过web访问用户帐户的坏人。用户名枚举-另一种被忽略的攻击面是由错误消息创建的攻击面。密码恢复就是一个很好的例子。攻击者输入电子邮件地址并单击"忘记密码"。如果应用程序返回消息"抱歉，此电子邮件地址不存在"，则攻击者知道该用户没有帐户。现在，如果他们输入另一个电子邮件地址却没有收到该邮件，他们就知道该电子邮件确实存在。然后，他们可以使用其他方法尝试访问该帐户，因为他们知道该帐户确实存在。字典攻击-这是暴力攻击的一种形式，攻击者试图通过编程输入常用密码来访问用户帐户。如果您的身份验证解决方案不强制使用强而复杂的密码，那么您的许多用户很可能会使用易受攻击的弱密码。独自管理所有这些是很困难的，但是使用Auth0这样的服务可以让您减轻很多责任！用户凭证是在Auth0端处理和存储的，因此，您不必担心如何更新最新的哈希函数和密码保护方法，而可以专注于构建自己应用程序的独特之处。多因素身份验证一旦您的密码安全锁定，您可能会开始问自己，这足够了吗？在上一节中，所涉及的一切都围绕单因素身份验证展开。即使你做的每件事都是正确的，仍然只有一个因素需要访问一个帐户：密码。使用多因素身份验证，您可以通过要求多个因素进行身份验证来添加额外的保护层。一般来说，这些因素可分为以下几类：你知道的-你知道的东西，比如密码。你所拥有的-你拥有的实物，比如手机。你是什么-生物特征数据，比如指纹，视网膜扫描等等。多因素身份验证的一个例子是要求用户输入用户名和密码才能登录，然后将一次性密码发送到他们的手机，他们必须将密码发回以进行身份验证。在这种情况下，即使攻击者知道用户的密码，也不够。他们还必须获得他们的电话，以提供OTP。实现多因素身份验证多因素身份验证解决了很多问题，可以大大减少应用程序的攻击面！那么，在实现多因素身份验证时，有哪些"难题"？一次性密码生成-在实现一次性密码检查时，需要记住一些事项。用户在被锁定之前可以请求多少次新的OTP？OTP应保持活动多久？如果用户丢失手机，您将提供什么恢复选项？由于实现MFA的复杂性和风险，大多数人都会将其转移到已经擅长它的外部服务上。用户体验-多因素身份验证的最大缺点是有时会以牺牲用户体验为代价。如果您要求用户下载晦涩的应用程序来接收OTP，因为这是最容易实现的解决方案，那么作为客户，您可能会失去他们。此外，您需要的每个因素都会增加应用程序的复杂性，这可能会无意中引入错误。如果您为您的用户提供了几种身份验证方法，那么您最好确保您能够支持所有这些方法，并使它们保持最新的最佳安全实践。使用Auth0，您可以从多个多因素身份验证选项中进行选择，只需单击一次即可将其打开！升级身份验证为了管理用户体验和安全性之间的平衡，有些人发现最好不要在每次登录时都要求MFA，而是在访问更敏感的数据时需要MFA。通过逐步身份验证，允许访问不同类型资源的应用程序可以要求用户使用更强大的身份验证机制来访问敏感资源。例如，应用程序