是时候演进认证安全了

身份攻击已变得普遍且影响重大。攻击者使用日益复杂的方式入侵特权系统，因此我们必须通过提升身份安全方法来保护账户。Okta致力于通过"安全身份承诺"等倡议引领行业对抗身份攻击。以下是保护应用程序的可操作步骤。

目录

• 身份保证是目标
• 解密认证因素
• 拥抱防钓鱼认证
• 避免弱认证方法
• 通过多因素认证提升认证安全
• 动态定制认证要求
• 通过应用身份安全概念构建安全应用
• 加入身份安全演进
• 了解更多关于防钓鱼认证、身份安全和保护应用程序的信息

身份保证是目标

当我们考虑认证时，我们考虑的是获取对敏感资源的访问权限。我们希望设置某种程度的屏障，使数据不会公开可用。但仅仅添加屏障是不够的。如果能够确保用户的凭证是唯一属于他们的，并且没有人能够冒充他们，这不是更有用吗？这不仅仅是围绕数据的围栏；我们还确保访问数据的用户确实是他们声称的身份。这在理论上听起来很棒。

在理想世界中，我们希望平衡安全要求与用户的舒适度。增加安全要求可能会增加用户的摩擦点。用户遇到的摩擦点越多，他们的满意度、参与度和应用程序使用率就越低——平衡点根据应用程序用户和数据敏感性而变化。例如，面向消费者的公共应用程序与组织内部使用的内部应用程序的要求可能不同。

让我们一起应对这种平衡行为，以便找到适合您需求的正确路径。

解密认证因素

在我们深入探讨可能的解决方案之前，让我们回顾一下三种认证因素类别：

你知道的东西 知识因素包括密码和PIN码

你拥有的东西 拥有因素包括智能卡、安全密钥、手机和平板电脑等设备

你的特征 推断因素包括指纹和面部识别等生物特征

认证依赖于一个或多个因素类别，在授予用户访问应用程序权限之前建立身份保证。

拥抱防钓鱼认证

最佳、更安全和推荐的认证方法是防钓鱼的。防钓鱼认证更难被黑客攻击，并减轻因拦截PIN码和登录链接而导致的未经授权访问。

防钓鱼认证依赖生物特征和专用设备或装备，以防止攻击者访问您的应用程序。

防钓鱼因素包括以下形式。

智能卡和PIV卡

大型企业、受监管行业和政府实体广泛使用智能卡和PIV卡。这些组织可能会发放智能卡，用于将个人配置文件附加到共享工作站访问，如在银行或医院中看到的那样。即使员工使用发放的笔记本电脑作为额外的安全措施，组织也可能向其员工发放卡片。

优点：安全，可以唯一绑定到用户，并在行业中得到良好利用 缺点：需要可能丢失或被盗的物理设备，由于硬件要求和便利性，不适合用于公共和消费者安全

安全密钥和硬件设备

硬件安全密钥是组织为其员工使用的另一种高级安全机制。安全密钥可以具有不同级别的安全性，从较旧且安全性较低的基于时间的一次性密码密钥，到需要手机等辅助设备的近场通信密钥，以及需要生物特征的密钥。为了获得最高级别的安全性，您需要使用具有生物特征功能的密钥和硬件。安全密钥通过将凭证存储在硬件上工作，这需要在您使用的每个设备上注册密钥。虽然插入计算机的密钥可能很熟悉，但具有生物特征功能的硬件（如笔记本电脑）和能够支持的软件也可以是防钓鱼认证因素。在具有生物特征功能的计算机上的Okta FastPass就是防钓鱼硬件设备的一个例子。

优点：基于生物特征的硬件设备非常安全。 缺点：可能需要物理设备，您需要在使用的每个设备上注册密钥，并且由于硬件要求和便利性，不适合用于公共和消费者安全。设备制造商可以使它们小巧轻便，以减轻对依赖笨重设备的担忧。但如果用户丢失或损坏此设备会发生什么？他们需要多长时间才能再次访问系统？

FIDO2与WebAuthn和Passkeys

FIDO2和WebAuthn结合是一个强大的认证因素，利用能够支持生物特征的设备和Web框架中的新功能来可靠地提高用户安全性。此因素需要符合FIDO标准的能够支持生物特征的设备（如手机或笔记本电脑）以及能够支持的软件。万维网联盟的Web认证规范意味着基于JavaScript的Web应用程序可以直接在浏览器中支持防钓鱼认证。防钓鱼硬件因素（如安全密钥或在生物特征设备上的Okta FastPass）与Passkeys之间的区别在于可发现性和凭证可移植性。可发现的FIDO认证不是将凭证存储在硬件上，而是将凭证存储在软件外部，例如在iCloud钥匙串或Android Keystore中。凭证存储使得在同一生态系统内的不同设备上对同一站点进行认证而无需重新注册成为可能。

优点：基于生物特征的FIDO认证安全，可扩展用于公共和消费者用户，并且无需携带安全密钥或卡片 缺点：每个应用程序必须支持此认证方法，并且消费者必须拥有能够支持的设备

为了达到最高级别的身份安全，请使用防钓鱼因素。

防钓鱼因素决策树

我们推荐在Okta使用防钓鱼因素，因为它们提供最佳的应用程序保护。您内置了身份保证以及认证安全性。请考虑此决策树以满足您的认证需求：

避免弱认证方法

我们不再生活在仅凭密码就足以保护敏感资源的世界中。研究表明，超过80%的数据泄露是由于凭证泄露造成的。我们必须通过避免弱凭证并偏好更强大的形式来提升认证方法。关注网络安全的行业领导者，包括Okta等公司、OWASP等非营利基金会以及NIST和NCSC等政府标准，以指导您使用强因素并避免弱因素。特别要警惕传统因素。

避免安全问题作为因素

网络安全组织不推荐安全问题，因为它们既不安全也不可靠。安全问题容易受到社会工程攻击。最好避免这种方法。

SMS一次性代码不安全

攻击者可以通过SIM交换和拦截攻击访问这些消息。NIST建议弃用SMS作为认证因素，因此请考虑替代认证方法。

基于电子邮件的基于时间的一次性密码具有与SMS类似的安全问题

使用电子邮件进行TOTP会带来与SMS代码类似的安全问题。攻击者可以拦截电子邮件。电子邮件可能被错误地标记为垃圾邮件。电子邮件传递延迟可能导致配置更长的有效时间，从而降低安全性。

避免密码反模式

密码必须通过允许更长的字符长度和字符种类来演进。避免复杂性要求和强制密码重置等反模式。通过检查密码与泄露密码数据库来强制执行强密码。密码管理器可以通过为每个站点推荐唯一的强密码并应用存储的密码来抵消用户风险。但是，密码管理器并非万无一失，用户可能为密码管理器本身使用不安全的密码。

这些因素确实为敏感资源提供了弱屏障，但缺少一个关键元素：身份保证。弱认证因素缺乏确保进行认证挑战的用户确实是他们声称的身份的保障措施。

通过多因素认证提升认证安全

仅使用密码需要谨慎，但密码与其他因素的组合可以提升身份安全。单个传统认证因素很少足够安全以保护任何资源；它不足以安全地访问您的用户和Okta配置。

添加支持TOTP和推送认证的认证器应用等因素会增加对敏感数据的屏障。提高屏障有助于保护您的应用程序，要求冒充者尝试黑客攻击账户付出更多努力。然而，使用最弱的认证因素组合不如防钓鱼认证强大。

结合强认证因素

确保认证安全和合理身份保证的最佳方法是结合中等到高的认证因素。这样做支持具有安全后备系统的良好安全性。例如，如果您在消费者场景中无法使用防钓鱼认证，请将密码与推送认证分层。允许消费者选择加入Passkeys，同时支持MFA。对于员工场景，除了Okta FastPass之外，还可以发放硬件密钥作为备份因素。

Okta的认证策略构建器可以帮助您创建强认证要求，以访问Okta服务和由Okta登录保护的应用程序，同时根据您的需求定制会话生命周期。

是时候演进我们应用程序的认证安全并偏好防钓鱼因素了。

动态定制认证要求

身份安全不是一刀切的解决方案。FIDO2与WebAuthn因素（如用于员工使用案例的Okta FastPass和用于消费者使用案例的Passkeys）可以成为标准方法。

考虑自适应MFA以进行条件认证要求

复杂的使用案例需要更多定制。您的需求可能会根据地理位置、IP地址、设备属性和威胁检测等使用因素而变化。身份提供商提供帮助您定制认证安全的解决方案。例如，Okta支持自适应MFA等功能，该功能根据上下文调整认证要求，以及身份威胁保护，该功能持续监控威胁并可以通过终止认证会话来做出反应。如果您的行业需要最高级别的身份安全，或者您的应用程序包含高度敏感的资源，请考虑这些选项。

为敏感资源请求重新验证身份

身份保证不必仅在应用程序入口处发生。当敏感操作和数据需要提升认证时，考虑使用Step Up Authentication Challenge来保护资源。Step Up Authentication Challenge是一个OAuth标准，用于在应用程序内执行操作时要求安全因素或最近的认证。

第三方交互可能需要身份保证。虽然我们主要将认证视为单独活动，但考虑有人呼叫帮助中心寻求支持的情况。帮助中心代理需要远程验证身份，我们不想仅依赖弱方法（如密码或PIN）。在这种情况下，考虑为您的应用程序使用客户端发起的后端认证。

所有这些建议对于在这些应用程序上工作的开发人员意味着什么？我们如何利用身份安全最佳实践？

通过应用身份安全概念构建安全应用

我们开发人员有一项艰巨的工作。我们必须确保我们的应用程序符合合规要求并防范安全威胁，同时还要交付产品功能。认证是基础，但不是您的整个产品线。这是一个期望，不会推动您的应用程序的产品创新，但如果实施不正确则有害。

使用支持OAuth 2.1和OpenID Connect的身份提供商

为了最好地保护您的应用程序并避免陷入实施认证的细节，尽可能将其委托给您的身份提供商。当您将认证委托给像Okta这样的IdP时，您可以访问行业认可的最佳实践，例如使用OAuth 2.1和OpenID Connect标准与用户重定向进行认证挑战。将用户重定向到Okta托管的登录小部件使您无需手动管理认证方法。它允许您利用登录小部件用户挑战与Okta身份引擎进行防钓鱼认证因素。使用Okta身份引擎意味着您的应用程序可以访问最新的安全身份管理功能。

将认证委托给您的身份提供商

当您将用户重定向到Okta进行登录时，您使认证成为Okta的问题。这很好，因为它为您提供了最大的安全性和最少的工作量。您的Okta管理员可以配置认证策略并向这些认证用户挑战添加业务规则。您不必担心如何在您的应用程序中实施WebAuthn，确保您拥有所有用户控件来处理推送通知，或跟踪登录上下文以适应认证因素。所有这些都已处理。您只需要知道用户是否完成了认证挑战，然后您可以返回交付功能。

如果您担心浏览器重定向登录会降低用户体验，或者如果您的应用程序的使用案例需要自定义外观，您可以自定义Okta托管的登录小部件的样式。当您将自定义品牌的登录小部件与自定义域结合使用时，您的用户可能永远不会知道他们离开了您的站点。我们正在继续构建此领域的功能，以便您可以同时满足安全身份和品牌要求。请关注有关自定义登录的内容。

使用经过审查和维护良好的OIDC客户端库

经过审查、维护良好的OIDC客户端库提高了实施速度，降低了开发人员工作量，并且最重要的是，对认证安全至关重要。因为OAuth 2.1和OIDC是开放标准，编写自己的代码来处理所需的事务很诱人。为了您的应用程序安全和良好认证库所需的持续维护工作，请抵制这种诱惑。例如，在像Proof-Key for Code Exchange验证步骤或令牌验证中遗漏某些内容时，很容易引入开发人员错误。许多更细微的错误可能对您的应用程序产生不利影响。抵制诱惑。

标准也可能随时间变化，例如添加新的保护机制或引入破坏性更改。编写自定义实现意味着更改和维护成为您的责任，并且您不能假定先前的规范知识足够好，因为规范可能变化。抵制诱惑并将此责任从您的盘子中移除。

理想情况下，使用经过审查、维护良好的OIDC客户端库，该库经过OIDC认证或使用Okta SDK。Okta的SDK不仅安全地为您处理OAuth握手和令牌存储，而且您还将获得对OAuth规范最新进展的内置支持，例如Step Up Authentication Challenge、CIBA等。

加入身份安全演进

通过使用防钓鱼因素提升认证因素来保护您的员工和客户。通过配置强认证策略让Okta为您工作。在您的Okta组织中启用动态认证因素和威胁检测，以减轻数据泄露并加强您的声誉。

在您的软件应用程序中，利用Okta SDK将用户重定向到Okta托管的登录小部件，以快速、高效、无缝地访问更安全的认证因素。然后，通过添加Step Up Authentication Challenge在您的应用程序中构建更多安全性以维护身份安全。保持更新最新的安全最佳实践并深思熟虑地集成OAuth规范对于安全身份管理至关重要。

应用这些关键要点

• 尽可能使用防钓鱼因素进行认证，根据使用案例和目标受众偏好Passkeys和Okta FastPass
• 提供强MFA选项作为备份认证方法
• 将身份管理和认证委托给支持OAuth 2.1和OIDC的身份提供商
• 使用OIDC客户端库将用户重定向到通过Okta托管的登录页面登录
• 考虑使用OAuth扩展规范在用户会话的整个生命周期中持续提升身份保证

了解更多关于防钓鱼认证、身份安全和保护应用程序的信息

我希望您感到有动力加入安全身份演进。如果您觉得这篇文章有趣，您可能喜欢以下内容：

• 如何保护未来的SaaS应用程序
• 引入CIBA用于安全交易验证
• 使用Angular和NestJS添加Step-up认证
• 为什么您应该从静态API令牌迁移到OAuth 2.0

记得在LinkedIn上关注我们并订阅我们的YouTube频道以获取更多精彩内容。我们也想听取您关于您想看到的主题和您可能有的问题的意见。在下面给我们留言！