Multifactor Authentication Cheat Sheet / 多因素认证速查表¶
Introduction / 介绍¶
Multifactor Authentication (MFA) requires evidence from at least two distinct authentication factors: something you know, something you have, and something you are. Location and other risk signals can inform authentication decisions, but do not substitute for an authentication factor, as explained in NIST SP 800-63B-4.
多因素认证（MFA）需要至少两个不同认证因素的证据：你知道的、你拥有的和你是的。位置和其他风险信号可以提供认证决策的信息，但不能替代认证因素，如NIST SP 800-63B-4中所述。
It should be noted that requiring multiple instances of the same authentication factor (such as needing both a password and a PIN) does not constitute MFA and offers minimal additional security. The factors used should be independent of each other and should not be able to be compromised by the same attack. While the following sections discuss the disadvantage and weaknesses of various different types of MFA, in many cases these are only relevant against targeted attacks. Any MFA is better than no MFA.
需要注意的是，要求同一认证因素的多实例（例如需要密码和PIN）并不构成MFA，并且提供的安全保障有限。使用的因素应相互独立，并且不应能够被同一攻击所破坏。虽然以下部分讨论了各种不同类型MFA的缺点和弱点，但在许多情况下，这些只有在针对特定攻击时才相关。任何MFA都比没有MFA好。
Advantages / 优点¶
The most common way that user accounts get compromised on applications is through weak, re-used or stolen passwords. Despite any technical security controls implemented on the application, users are liable to choose weak passwords, or to use the same password on different applications. As developers or system administrators, it should be assumed that users' passwords will be compromised at some point, and the system should be designed in order to defend against this.
用户账户在应用程序上被入侵的最常见方式是通过弱密码、重复使用或被盗的密码。尽管在应用程序上实施了任何技术安全控制，但用户可能会选择弱密码，或者在不同的应用程序上使用相同的密码。作为开发者或系统管理员，应该假设用户的密码最终会被破解，并且系统应该设计成防御这种攻击。
MFA is by far the best defense against the majority of password-related attacks, including brute-force, credential stuffing and password spraying, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises.
MFA是抵御大多数与密码相关的攻击的最佳防御手段，包括暴力破解、凭证填充和密码喷洒，微软的分析表明它将阻止99.9%的账户入侵。
Disadvantages / 缺点¶
The biggest disadvantage of MFA is the increase in management complexity for both administrators and end users. Many less technical users may find it difficult to configure and use MFA. Additionally, there are a number of other common issues encountered:
多因素认证（MFA）的最大缺点是增加了管理员和最终用户的管理复杂性。许多技术程度较低的用户可能会发现配置和使用MFA很困难。此外，还遇到了一些其他常见问题：
- Types of MFA that require users to have specific hardware can introduce significant costs and administrative overheads.
中文：需要用户拥有特定硬件的MFA类型可能会引入显著的成本和管理开销。 - Users may become locked out of their accounts if they lose or are unable to use their other factors.
中文：如果用户丢失或无法使用其他因素，他们可能会被锁定在自己的账户之外。 - MFA introduces additional complexity into the application.
中文：MFA将额外的复杂性引入了应用程序中。 - Many MFA solutions add external dependencies to systems, which can introduce security vulnerabilities or single points of failure.
中文：许多MFA解决方案向系统中添加了外部依赖，这可能会引入安全漏洞或单点故障。 - Processes implemented to allow users to bypass or reset MFA may be exploitable by attackers.
中文：实施以允许用户绕过或重置MFA的流程可能被攻击者利用。 - Requiring MFA may prevent some users from accessing the application.
中文：要求使用MFA可能会阻止一些用户访问应用程序。
Quick Recommendations / 快速建议¶
Exactly when and how MFA is implemented in an application will vary on a number of different factors, including the threat model of the application, the technical level of the users, and the level of administrative control over the users. These need to be considered on a per-application basis.
应用程序中多因素认证（MFA）的具体实施时间和方式将受到多种不同因素的影响，包括应用程序的威胁模型、用户的技术水平以及用户的管理控制水平。这些因素需要针对每个应用程序进行考虑。
However, the following recommendations are generally appropriate for most applications, and provide an initial starting point to consider.
然而，以下建议通常适用于大多数应用程序，并提供了一个初步的起点来考虑。
- Require some form of MFA for all users.
中文：要求所有用户都必须采用某种形式的MFA。 - Provide the option for users to enable MFA on their accounts using TOTP.
中文：提供用户使用TOTP启用账户MFA的选项。 - Require MFA for administrative or other high privileged users.
中文：要求对管理员或其他高权限用户实施MFA。 - Implement a secure procedure to allow users to reset their MFA.
中文：实施一个安全的流程，允许用户重置他们的MFA。 - Consider MFA as a service.
中文：考虑MFA作为服务。
Implementing MFA / 实施MFA¶
MFA is a critical security control, and is recommended for all applications. The following sections provide guidance on how to implement MFA, and the considerations that should be taken into account.
多因素认证是关键的安全控制措施，建议所有应用程序都采用。以下章节提供了如何实施多因素认证以及应考虑的因素的指导。
Regulatory and Compliance Requirements / 法规和合规要求¶
Many industries and countries have regulations that require the use of MFA. This is particularly common in the finance and healthcare sectors, and is often required in order to comply with the General Data Protection Regulation (GDPR) in the European Union. It is important to consider these requirements when implementing MFA.
许多行业和国家都有规定要求使用多因素认证。这在金融和医疗保健领域尤为常见，并且通常需要遵守欧盟的通用数据保护条例（GDPR）。在实施多因素认证时考虑这些要求非常重要。
When to Require MFA / 何时需要多因素认证¶
The most important place to require MFA on an application is when the user logs in. However, depending on the functionality available, it may also be appropriate to require MFA for performing sensitive actions, such as:
在应用程序上需要多因素认证最重要的地方是用户登录时。然而，根据可用的功能，在执行敏感操作时也可能需要多因素认证，例如：
- Changing passwords or security questions.
中文：更改密码或安全问题。 - Changing the email address associated with the account.
中文：更改与账户关联的电子邮件地址。 - Disabling MFA.
中文：禁用多因素认证。 - Elevating a user session to an administrative session.
中文：提升用户会话为管理员会话
If the application provides multiple ways for a user to authenticate these should all require MFA, or have other protections implemented. A common area that is missed is if the application provides a separate API that can be used to login, or has an associated mobile application.
如果应用程序提供了多种用户认证方式，这些方式都应该要求多因素认证（MFA），或者实施其他保护措施。一个常见的疏忽领域是，如果应用程序提供了可以用于登录的单独API，或者有相关的移动应用程序。
One-Time Password (OTP) Handling and Storage / 一次性密码（OTP）的处理和存储¶
OTPs are authentication secrets and should be handled with password-like hygiene. While their security traits differ from long-lived passwords, improper handling can still lead to user account compromise.
OTP是认证秘密，应该像密码一样进行管理。虽然它们的安保特性与长期密码不同，但不当处理仍然可能导致用户账户被入侵。
At a minimum, OTP implementations SHOULD:
至少，OTP实现应该：
- Enforce a short time-to-live (TTL)
中文：强制执行短生存时间（TTL） - Ensure OTPs are single use
中文：确保OTP是一次性使用的 - Apply strict attempt limits
中文：应用严格的尝试限制 - Invalidate the OTP on successful verification
中文：在验证成功后使OTP失效
OTP implementations SHOULD NOT:
OTP实现不应：
- Log OTP values
中文：记录OTP值 - Store OTPs in long-term plaintext form
中文：以明文形式长期存储OTP
To further reduce risk and limit exposure, it is RECOMMENDED to:
为了进一步降低风险和限制暴露，建议：
- Generate OTPs using a cryptographically secure random number generator
中文：使用密码学安全的随机数生成器生成OTP - Consider 8-digit or longer codes where usability allows
中文：在可用性允许的情况下考虑8位或更长的代码 - On "resend", generate a new OTP and overwrite the old record
中文：在“重新发送”时，生成新的OTP并覆盖旧记录
Hashing OTPs / 哈希一次性密码¶
Hashing OTPs is still recommended, but for different reasons than password hashing. OTPs typically have a very small keyspace (for example, ~1 million possibilities for a 6-digit code), which means a database attacker can brute-force any OTP hash quickly.
哈希一次性密码仍然推荐，但原因与密码哈希不同。一次性密码通常具有非常小的密钥空间（例如，6位密码有大约100万种可能性），这意味着数据库攻击者可以快速穷举任何一次性密码的哈希值。
As a result, hashing OTPs does not provide strong offline attack resistance in the way password hashing does.
因此，哈希一次性密码在提供离线攻击抵抗方面并不像密码哈希那样强大。
However, hashing remains useful to:
然而，哈希仍然有用，可以：
- Prevent accidental disclosure via logs, metrics, or debugging tools
中文：防止通过日志、指标或调试工具意外泄露 - Reduce blast radius if the database is briefly exposed during the OTP’s validity window
中文：在一次性密码的有效窗口期间，如果数据库短暂暴露，减少影响范围 - Enforce good secret-handling discipline and avoid plaintext storage by default
中文：强制执行良好的秘密处理纪律，并默认避免明文存储
The goal is short-term exposure protection, not long-term cryptographic secrecy.
目标是短期暴露保护，而不是长期加密保密。
Improving User Experience / 提升用户体验¶
Risk Based Authentication / 基于风险的认证¶
Having to frequently login with MFA creates an additional burden for users, and may cause them to disable MFA on the application. Risk based authentication can be used to reduce the frequency of MFA prompts, by only requiring MFA when the user is performing an action that is considered to be high risk. Some examples of this include:
频繁使用多因素认证会给用户带来额外负担，并可能导致他们在应用程序上禁用多因素认证。基于风险的认证可以通过仅在用户执行被认为风险较高的操作时要求多因素认证，来减少MFA提示的频率。以下是一些例子：
- Requiring MFA when the user logs in from a new device or location.
中文：当用户从新设备或位置登录时要求MFA。 - Requiring MFA when the user logs in from a location that is considered to be high risk.
中文：当用户从被认为风险较高的位置登录时要求MFA。 - Using corporate IP ranges or geolocation as risk signals when deciding whether to require additional authentication.
中文：在决定是否需要额外的认证时，使用企业IP范围或地理位置作为风险信号。
Passkeys / 密钥凭证¶
Passkeys can provide phishing-resistant MFA by combining possession of the credential private key with local PIN or biometric verification. When using passkeys as MFA, require user verification and validate the returned user-verification flag on the server; a touch confirming user presence alone is not a second factor. The credential key pair is created during registration; authentication uses the existing private key to sign a challenge. For registration, verification, and recovery guidance, see the Passkey Security Cheat Sheet.
密钥凭证可以通过结合凭证私钥的持有与本地PIN或生物识别验证，提供抗钓鱼的多因素认证。当使用密钥凭证作为MFA时，要求用户验证并在服务器上验证返回的用户验证标志；仅触摸确认用户存在本身不是一个第二因素。凭证密钥对是在注册期间创建的；认证使用现有的私钥来签署挑战。有关注册、验证和恢复的指导，请参阅密钥凭证安全速查表。
Failed Login Attempts / 失败登录尝试¶
When a user enters their password, but fails to authenticate using a second factor, this could mean one of two things:
当用户输入密码但无法使用第二因素进行身份验证时，这可能意味着以下两种情况之一：
- The user has lost their second factor, or doesn't have it available (for example, they don't have their mobile phone, or have no signal).
中文：用户丢失了第二因素，或者无法使用（例如，他们没有手机，或者没有信号）。 - The user's password has been compromised.
中文：用户的密码已被泄露。
There are a number of steps that should be taken when this occurs:
当发生这种情况时，应采取以下步骤：
- Prompt the user to try another form of MFA.
中文：提示用户尝试另一种形式的MFA（多因素认证）。 - Allow the user to attempt to reset their MFA.
中文：允许用户尝试重置他们的MFA。 - Notify the user of the failed login attempt, and encourage them to change their password if they don't recognize it.
中文：通知用户失败的登录尝试，并鼓励他们在不认识该密码的情况下更改密码。- The notification should include the time, browser and geographic location of the login attempt.
中文：通知应包含登录尝试的时间、浏览器和地理位置。 - This should be displayed next time they login, and optionally emailed to them as well.
中文：这些信息将在他们下次登录时显示，并且可以选择性地通过电子邮件发送给他们。
- The notification should include the time, browser and geographic location of the login attempt.
Resetting MFA / 重置多因素认证¶
One of the biggest challenges with implementing MFA is handling users who forget or lose their additional factors. There are many ways this could happen, such as:
实施多因素认证时最大的挑战之一是处理忘记或丢失额外因素的用户。这种情况可能以多种方式发生，例如：
- Re-installing a workstation without backing up digital certificates.
中文：在没有备份数字证书的情况下重新安装工作站。 - Wiping or losing a phone without backing up OTP codes.
中文：擦除或丢失手机而没有备份OTP代码。 - Changing mobile numbers.
中文：更改手机号码。
In order to prevent users from being locked out of the application, there needs to be a mechanism for them to regain access to their account if they can't use their existing MFA; however it is also crucial that this doesn't provide an attacker with a way to bypass MFA and hijack their account.
为了防止用户被锁定在应用程序之外，需要有一种机制，让用户在无法使用现有的MFA时能够恢复对账户的访问；然而，这也至关重要，不能为攻击者提供绕过多因素认证并劫持账户的方法。
There is no definitive "best way" to do this, and what is appropriate will vary hugely based on the security of the application, and also the level of control over the users. Solutions that work for a corporate application where all the staff know each other are unlikely to be feasible for a publicly available application with thousands of users all over the world. Every recovery method has its own advantages and disadvantages, and these need to be evaluated in the context of the application.
没有一种确定的最佳方式来做这件事，合适的方法将根据应用程序的安全性以及用户控制水平而有很大差异。对于所有员工都互相认识的内部应用程序，适用的解决方案可能不适合面向全球成千上万的公开应用程序。每种恢复方法都有其自身的优缺点，这些需要在应用程序的上下文中进行评估。
Some suggestions of possible methods include:
以下是一些可能的方法建议：
- Providing the user with a number of single-use recovery codes when they first setup MFA.
中文：在用户首次设置多因素认证（MFA）时，向用户提供多个一次性恢复代码。 - Requiring the user to setup multiple types of MFA (such as a digital certificate, OTP core and phone number for SMS), so that they are unlikely to lose access to all of them at once.
中文：要求用户设置多种类型的MFA（如数字证书、OTP核心和用于短信的手机号码），这样他们不太可能一次性失去所有访问权限。 - Mailing a one-use recovery code (or new hardware token) to the user's registered address.
中文：将一次性恢复代码（或新的硬件令牌）邮寄到用户的注册地址。 - Requiring the user contact the support team and having a rigorous process in place to verify their identity.
中文：要求用户联系支持团队，并建立严格的过程来验证他们的身份。 - Requiring another trusted user to vouch for them.
中文：要求另一个受信任的用户为他们担保。
Changing MFA Factors / 更改MFA因素¶
Users may need to update their authentication factors, such as changing a phone number, migrating to a new authenticator app, or replacing a lost hardware token. Because attackers can exploit this process to take over accounts, it must be strictly secured.
用户可能需要更新其身份验证因素，例如更改电话号码、迁移到新的身份验证器应用或更换丢失的硬件令牌。因为攻击者可以利用这个过程来接管账户，所以必须严格保护这一过程。
Best practices include:
最佳实践包括：
- Require reauthentication with an existing enrolled factor before allowing changes.
中文：在允许更改之前，要求使用现有注册因素进行重新认证。 - Do not rely solely on the active session, as it may be hijacked.
中文：不要仅依赖于活跃会话，因为它可能被劫持。 - Treat factor replacement as a high-risk action and apply risk-based checks (e.g., new device, unusual location).
中文：将因素替换视为高风险操作，并应用基于风险的检查（例如，新设备、不寻常的位置）。 - Notify the user through out-of-band channels (such as email or push notification) whenever an MFA factor is changed.
中文：每当更改MFA因素时，通过非绑定渠道（如电子邮件或推送通知）通知用户。 - Consider applying delays or step-up verification for high-value accounts.
中文：考虑为高价值账户应用延迟或提升验证。
This ensures that even if a session is compromised, attackers cannot silently replace the user’s MFA factors and lock the legitimate user out.
这确保了即使会话被破坏，攻击者也无法静默替换用户的MFA因素并将合法用户锁定在外.
Consider Using a Third Party Service / 考虑使用第三方服务¶
There are a number of third party services that provide MFA as a service. These can be a good option for applications that don't have the resources to implement MFA themselves, or for applications that require a high level of assurance in their MFA. However, it is important to consider the security of the third party service, and the implications of using it. For example, if the third party service is compromised, it could allow an attacker to bypass MFA on all of the applications that use it.
有许多第三方服务提供多因素认证作为服务。这对于没有资源自行实施多因素认证的应用程序，或者需要高保障级别多因素认证的应用程序来说，是一个不错的选择。然而，考虑第三方服务的安全性以及使用它的后果是很重要的。例如，如果第三方服务被入侵，可能会允许攻击者绕过使用该服务的所有应用程序的多因素认证。
Something You Know / 你知道的某物¶
Knowledge-based, the most common type of authentication is based on something the users knows - typically a password. The biggest advantage of this factor is that it has very low requirements for both the developers and the end user, as it does not require any special hardware, or integration with other services.
基于知识的认证是最常见的认证类型，它基于用户知道的东西——通常是密码。这个因素的最大优点是，它对开发人员和最终用户的要求非常低，因为它不需要任何特殊硬件或与其他服务的集成。
Passwords and PINs / 密码和PIN码¶
Passwords and PINs are the most common form of authentication due to the simplicity of implementing them. The Authentication Cheat Sheet has guidance on how to implement a strong password policy, and the Password Storage Cheat Sheet has guidance on how to securely store passwords. Most multifactor authentication systems make use of a password, as well as at least one other factor.
由于实施简单，密码和PIN码是最常见的认证形式。认证速查表提供了如何实施强密码策略的指导，而密码存储速查表提供了如何安全存储密码的指导。大多数多因素认证系统都使用密码，以及至少另一个因素。
Pros / 优点¶
- Simple and well understood.
中文：简单且易于理解 - Native support in every authentication framework.
中文：每个认证框架的原生支持。 - Easy to implement.
中文：易于实现。
Cons / 缺点¶
- Users are prone to choosing weak passwords.
中文：用户容易选择弱密码。 - Passwords are commonly re-used between systems.
中文：密码在系统间通常会被重复使用。 - Susceptible to phishing.
中文：容易受到钓鱼攻击。
Security Questions / 安全问题¶
Security questions are no longer recognized as an acceptable authentication factor per NIST SP 800-63. Account recovery is just an alternate way to authenticate so it should be no weaker than regular authentication.
根据NIST SP 800-63，安全问题不再被视为可接受的认证因素。账户恢复只是另一种认证方式，因此它不应比常规认证更弱。
Pros / 优点¶
- None that are not also present in passwords.
中文：没有那些也存在于密码中的。
Cons / 缺点¶
- No longer recognized as an acceptable authentication factor.
中文：不再被视为可接受的认证因素。 - Questions often have easily guessable answers.
中文：问题通常有容易被猜到的答案。 - Answers to questions can often be obtained from social media or other sources.
中文：问题的答案通常可以从社交媒体或其他来源获得。 - Questions must be carefully chosen so that users will remember answers years later.
中文：问题必须仔细选择，以便用户多年后还能记住答案。 - Susceptible to phishing.
中文：容易受到钓鱼攻击。
Something You Have / 你所拥有的东西¶
Possession-based authentication is based on the user having a physical or digital item that is required to authenticate. This is the most common form of MFA, and is often used in conjunction with passwords. The most common types of possession-based authentication are hardware and software tokens, and digital certificates. If properly implemented then this can be significantly more difficult for a remote attacker to compromise; however it also creates an additional administrative burden on the user, as they must keep the authentication factor with them whenever they wish to use it.
基于所有权的身份验证是基于用户拥有一个物理或数字物品，该物品是进行身份验证所必需的。这是最常见的一种多因素认证形式，通常与密码一起使用。最常见的基于所有权的身份验证类型是硬件和软件令牌，以及数字证书。如果实施得当，这将对远程攻击者构成更大的挑战；然而，这也给用户带来了额外的管理负担，因为他们必须随身携带身份验证因素，以便在需要时使用它。
One-Time Password Tokens / 一次性密码令牌¶
One-Time Password (OTP) tokens are a form of possession-based authentication, where the user is required to submit a constantly changing numeric code in order to authenticate. The most common of which is Time-based One-Time Password (TOTP) tokens, which can be both hardware and software based.
一次性密码（OTP）令牌是一种基于所有权的身份验证形式，用户需要提交一个不断变化的数字代码以进行身份验证。其中最常见的是基于时间的一次性密码（TOTP）令牌，这些令牌可以是硬件或软件形式的。
Hardware OTP Tokens / 硬件OTP令牌¶
Hardware OTP Tokens generate a constantly changing numeric codes, which must be submitted when authenticating. Most well-known of these is the RSA SecureID, which generates a six digit number that changes every 60 seconds.
硬件OTP令牌生成不断变化的数字代码，这些代码在身份验证时必须提交。其中最著名的是RSA SecureID，它每60秒生成一个六位数的数字。
Pros / 优点¶
- As the tokens are separate physical devices, they are almost impossible for an attacker to compromise remotely.
中文：由于令牌是独立的物理设备，攻击者几乎不可能远程攻击并使其受损。 - Tokens can be used without requiring the user to have a mobile phone or other device.
中文：令牌可以在不要求用户拥有手机或其他设备的情况下使用。
Cons / 缺点¶
- Deploying physical tokens to users is expensive and complicated.
中文：向用户部署物理令牌既昂贵又复杂。 - If a user loses their token it could take a significant amount of time to purchase and ship them a new one.
中文：如果用户丢失了令牌，可能需要花费大量时间购买并邮寄新的令牌给他们。 - Some implementations require a backend server, which can introduce new vulnerabilities as well as a single point of failure.
中文：某些实现需要后端服务器，这可能会引入新的漏洞以及单点故障问题。 - Stolen tokens can be used without a PIN or device unlock code.
中文：被盗的令牌可以在没有PIN码或设备解锁码的情况下使用。 - Susceptible to phishing (although short-lived).
中文：容易受到钓鱼攻击（尽管持续时间短暂）。
Software OTP Tokens / 软件OTP令牌¶
A cheaper and easier alternative to hardware tokens is using software to generate Time-based One-Time Password (TOTP) codes. This would typically involve the user installing a TOTP application on their mobile phone, and then scanning a QR code provided by the web application which provides the initial seed. The authenticator app generates a numeric code using a configured time step; RFC 6238 recommends a default of 30 seconds. The app and server must use the same time-step value.
使用软件生成基于时间的单次密码（TOTP）代码是一种比硬件令牌更便宜、更简单的替代方案。这通常涉及用户在他们的手机上安装一个TOTP应用程序，然后扫描由提供初始种子的Web应用程序提供的二维码。认证应用程序使用配置的时间步长生成一个数字代码；RFC 6238建议默认为30秒。应用程序和服务器必须使用相同的时间步长值。
Most websites use standardized TOTP tokens, allowing the user to install any authenticator app that supports TOTP. However, a small number of applications use their own variants of this (such as Symantec), which requires the users to install a specific app in order to use the service. This should be avoided in favor of a standards-based approach.
大多数网站使用标准化的TOTP令牌，允许用户安装任何支持TOTP的认证应用程序。然而，少数应用程序使用自己的变体（如Symantec），这要求用户安装特定的应用程序才能使用该服务。应避免使用这种方法，而应采用基于标准的方法。
Pros / 优点¶
- The absence of physical tokens greatly reduces the cost and administrative overhead of implementing the system.
中文：物理令牌的缺失大大降低了实施系统的成本和管理开销。 - When users lose access to their TOTP app, a new one can be configured without needing to ship a physical token to them.
中文：当用户失去对他们的TOTP应用程序的访问权限时，可以配置一个新的应用程序，而无需向他们发送物理令牌。 - TOTP is widely used, and many users will already have at least one TOTP app installed.
中文：TOTP被广泛使用，许多用户已经安装了至少一个TOTP应用程序。 - A screen lock reduces theft risk but does not guarantee protection if the phone is stolen while unlocked. Enable authenticator-app access protection where available; for example, Google Authenticator’s Privacy Screen requires device verification before app use.
中文：屏幕锁定可以降低盗窃风险，但如果不锁屏时手机被盗，则不能保证保护。在可用的情况下启用认证器应用访问保护；例如，Google Authenticator的隐私屏幕在使用应用前需要设备验证。
Cons / 缺点¶
- TOTP apps are usually installed on mobile devices, which are vulnerable to compromise.
中文：TOTP应用程序通常安装在移动设备上，这些设备容易受到攻击。 - The TOTP app may be installed on the same mobile device (or workstation) that is used to authenticate.
中文：TOTP应用程序可能安装在用于认证的同一移动设备（或工作站）上。 - Users may store the backup seeds insecurely.
中文：用户可能在不安全的方式下存储备份种子。 - Not all users have mobile devices to use with TOTP.
中文：并非所有用户都有手机设备来使用TOTP. - If the user's mobile device is lost, stolen or out of battery, they will be unable to authenticate.
中文：如果用户的手机设备丢失、被盗或电量耗尽，他们将无法进行身份验证。 - Susceptible to phishing (although short-lived).
中文：容易受到钓鱼攻击（尽管持续时间短暂）。
Universal Second Factor / 通用第二因素¶
Hardware U2F tokens
硬件U2F令牌
Universal Second Factor (U2F) is a standard for USB/NFC hardware tokens that implement challenge-response based authentication, rather than requiring the user to manually enter the code. This would typically be done by the user pressing a button on the token, or tapping it against their NFC reader. The most common U2F token is the YubiKey.
通用第二因素（U2F）是一种USB/NFC硬件令牌标准，它实现了基于挑战-响应的身份验证，而不是要求用户手动输入代码。这通常是通过用户在令牌上按按钮或将其轻触到NFC读卡器上完成的。最常见的U2F令牌是YubiKey。
Pros / 优点¶
- U2F tokens are resistant to phishing since the private key never leaves the token.
中文：U2F令牌对钓鱼攻击具有抵抗力，因为私钥永远不会离开令牌。 - Users can simply press a button rather than typing in a code.
中文：用户只需按按钮，而无需输入代码。 - As the tokens are separate physical devices, they are almost impossible for an attacker to compromise remotely.
中文：由于令牌是独立的物理设备，攻击者几乎不可能远程攻击并使其受损。 - U2F is natively supported by a number of major web browsers.
中文：许多主流网络浏览器原生支持U2F。 - U2F tokens can be used without requiring the user to have a mobile phone or other device.
中文：U2F令牌可以在不要求用户拥有手机或其他设备的情况下使用。
Cons / 缺点¶
- As with hardware OTP tokens, the use of physical tokens introduces significant costs and administrative overheads.
中文：与硬件OTP令牌一样，使用物理令牌会引入显著的成本和管理开销。 - Stolen tokens can be used without a PIN or device unlock code.
中文：被盗的令牌可以在没有PIN码或设备解锁码的情况下使用。 - As the tokens are usually connected to the workstation via USB, users are more likely to forget them.
中文：由于令牌通常通过USB连接到工作站，用户更容易忘记它们。
Certificates / 证书¶
Digital certificates are files that are stored on the user's device which are automatically provided alongside the user's password when authenticating. The most common type is X.509 certificates more commonly known as client certificates. Certificates are supported by all major web browsers, and once installed require no further interaction from the user. The certificates should be linked to an individual's user account in order to prevent users from trying to authenticate against other accounts.
数字证书是存储在用户设备上的文件，在用户进行身份验证时自动与用户密码一起提供。最常见的是X.509证书，通常称为客户端证书。所有主流网络浏览器都支持证书，一旦安装，无需用户进一步交互。证书应与个人的用户账户关联，以防止用户尝试在其他账户上进行身份验证。
Pros / 优点¶
- There is no need to purchase and manage hardware tokens.
中文：无需购买和管理硬件令牌。 - Once installed, certificates are very simple for users.
中文：安装后，证书对用户来说非常简单。 - Certificates can be centrally managed and revoked.
中文：证书可以集中管理和撤销。 - Resistant to phishing.
中文：抵抗钓鱼攻击
Cons / 缺点¶
- Using digital certificates requires a backend Private Key Infrastructure (PKI).
中文：使用数字证书需要后端私钥基础设施（PKI） - Installing certificates can be difficult for users, particularly in a highly restricted environment.
中文：用户安装证书可能会很困难，尤其是在高度受限的环境中 - Enterprise proxy servers which perform SSL decryption will prevent the use of certificates.
中文：执行SSL解密的 企业代理服务器 将阻止使用证书 - The certificates are stored on the user's workstation, and as such can be stolen if their system is compromised.
中文：证书存储在用户的工作站上，因此如果系统被入侵，可能会被盗
Smart Cards / 智能卡¶
Smartcards are credit-card size cards with a chip containing a digital certificate for the user, which is unlocked with a PIN. They are commonly used for operating system authentication, but are rarely used in web applications.
智能卡是信用卡大小的卡片，其中包含用户的数字证书，并通过PIN解锁。它们通常用于操作系统认证，但在Web应用程序中很少使用
Pros / 优点¶
- Stolen smartcards cannot be used without the PIN.
中文：被盗的智能卡没有PIN无法使用 - Smartcards can be used across multiple applications and systems.
中文：智能卡可以跨多个应用程序和系统使用。 - Resistant to phishing.
中文：抵抗钓鱼攻击
Cons / 缺点¶
- Managing and distributing smartcards has the same costs and overheads as hardware tokens.
中文：管理和分发智能卡的成本和开销与硬件令牌相同。 - Smartcards are not natively supported by modern browsers, so require third party software.
中文：智能卡不是现代浏览器原生支持的，因此需要第三方软件。 - Although most business-class laptops have smartcard readers built-in, home systems often do not.
中文：尽管大多数商用笔记本电脑都内置了智能卡读卡器，但家庭系统通常没有。 - The use of smartcards requires backend PKIs.
中文：使用智能卡需要后端PKI。
SMS Messages and Phone Calls / 短信消息和电话呼叫¶
[!WARNING]
中文：[!警告] NIST SP 800-63B-4 designates SMS and PSTN-delivered codes as a restricted authenticator because of SS7 interception, SIM-swap, and number-porting attacks. Do not use SMS for high-value or PII-handling applications. Where it is the only available factor, document the risk acceptance, enforce per-account rate limits, monitor for SIM-swap signals, and plan migration to TOTP, push notifications, or WebAuthn/FIDO2.
中文：NIST SP 800-63B-4 将短信和PSTN送达的代码指定为 受限 认证器，因为存在SS7拦截、SIM卡交换和号码携带攻击。不要使用短信进行高价值或PII处理应用。如果它是唯一可用的因素，请记录风险接受情况，执行按账户速率限制，监控SIM卡交换信号，并计划迁移到TOTP、推送通知或WebAuthn/FIDO2。
SMS messages or phone calls can be used to provide users with a single-use code that they must submit as an additional factor. Due to the risks posed by these methods, they should not be used to protect applications that hold Personally Identifiable Information (PII) or where there is financial risk. e.g. healthcare and banking. NIST SP 800-63B classifies these as restricted authenticators and discourages their use for applications containing PII.
短信消息或电话呼叫可以用来向用户提供一次性代码，他们必须将其作为额外因素提交。由于这些方法带来的风险，不应使用它们来保护包含个人身份信息（PII）的应用程序或存在财务风险的情况。例如，医疗保健和银行。NIST SP 800-63B将这些分类为受限认证器，并反对在包含PII的应用程序中使用它们。
Pros / 优点¶
- Relatively simple to implement.
中文：相对容易实现。 - Requires user to link their account to a mobile number.
中文：需要用户将他们的账户与手机号码关联。
Cons / 缺点¶
- Requires the user to have a mobile device or landline.
中文：需要用户拥有手机或固定电话。 - Require user to have signal or internet access to receive the call or message.
中文：需要用户有信号或互联网接入以接收通话或短信。 - Calls and SMS messages may cost money to send need to protect against attackers requesting a large number of messages to exhaust funds.
中文：发送通话和短信可能需要付费，需要防止攻击者请求大量短信以耗尽资金。 - Susceptible to SIM swapping attacks.
中文：容易受到SIM卡交换攻击。 - SMS messages may be received on the same device the user is authenticating from.
中文：短信可能会在用户进行身份验证的同一设备上接收。 - Susceptible to phishing.
中文：容易受到钓鱼攻击。 - SMS may be previewed when the device is locked.
中文：当设备锁定时，短信可能会被预览。 - SMS may be read by malicious or insecure applications.
中文：短信可能被恶意或不安全的应用程序读取。
Email / 电子邮件¶
Email verification requires that the user enters a code or clicks a link sent to their email address. There is some debate as to whether email constitutes a form of MFA, because if the user does not have MFA configured on their email account, it simply requires knowledge of the user's email password (which is often the same as their application password). However, it is included here for completeness.
电子邮件验证要求用户输入发送到其电子邮件地址的代码或点击链接。关于电子邮件是否构成多因素认证（MFA）的一种形式存在一些争议，因为如果用户在其电子邮件账户上未配置MFA，则只需知道用户的电子邮件密码（这通常与应用程序密码相同）。然而，这里将其包括在内以示完整。
Pros / 优点¶
- Very easy to implement.
中文：非常容易实现。 - No requirements for separate hardware or a mobile device.
中文：不需要单独的硬件或移动设备。
Cons / 缺点¶
- Relies entirely on the security of the email account, which often lacks MFA.
中文：完全依赖于电子邮件账户的安全性，而电子邮件账户通常缺乏MFA。 - Email passwords are commonly the same as application passwords.
中文：电子邮件密码通常与应用程序密码相同。 - Provides no protection if the user's email is compromised first.
中文：如果用户的电子邮件首先被泄露，则没有任何保护作用。 - Email may be received by the same device the user is authenticating from.
中文：用户可能通过其认证设备接收电子邮件。 - Susceptible to phishing.
中文：容易受到钓鱼攻击。
Something You Are / 你是某物¶
Inherence-based authentication is based on the physical attributes of the user. This is less common for web applications as it requires the user to have specific hardware, and is often considered to be the most invasive in terms of privacy. However, it is commonly used for operating system authentication, and is also used in some mobile applications.
基于属性的认证依赖于用户的物理特征。在Web应用程序中这较为少见，因为它要求用户拥有特定的硬件，并且通常被认为在隐私方面最具侵入性。然而，它常用于操作系统认证，也用于一些移动应用程序。
Biometrics / 生物识别¶
The are a number of common types of biometrics that are used, including:
常用的生物识别类型包括：
- Fingerprint scans
中文：指纹扫描 - Facial recognition
中文：面部识别 - Iris scans
中文：虹膜扫描 - Voice recognition
中文：语音识别
Pros / 优点¶
- Well-implemented biometrics are hard to spoof, and require a targeted attack.
中文：实施良好的生物识别技术难以伪造，并且需要针对性的攻击。 - Fast and convenient for users.
中文：对用户来说快速且方便。
Cons / 缺点¶
- Manual enrollment is required for the user.
中文：用户需要手动注册。 - Custom (sometimes expensive) hardware is often required to read biometrics.
中文：通常需要定制（有时昂贵的）硬件来读取生物识别信息。 - Privacy concerns: Sensitive physical information must be stored about users.
中文：隐私担忧：必须存储关于用户的敏感物理信息。 - If compromised, biometric data can be difficult to change.
中文：如果遭到破坏，生物识别数据可能难以更改。 - Hardware may be vulnerable to additional attack vectors.
中文：硬件可能容易受到其他攻击向量的影响。
Somewhere You Are / 您所在的位置¶
Location can inform access restrictions and risk-based authentication decisions. It is not an independent authentication factor: a password combined with a trusted IP address or location does not constitute MFA. NIST SP 800-63B-4 explicitly distinguishes these risk signals from authentication factors.
位置可以用来确定访问限制和基于风险的认证决策。它不是一个独立的认证因素：密码与受信任的IP地址或位置的组合并不构成多因素认证。NIST SP 800-63B-4明确区分了这些风险信号与认证因素。
Source IP Address / 源IP地址¶
The source IP address the user is connecting from can be used as a risk signal or access restriction, typically in an allow-list based approach. This could either be based on a static list (such as corporate office ranges) or a dynamic list (such as previous IP addresses the user has authenticated from).
用户连接的源IP地址可以用作风险信号或访问限制，通常采用基于允许列表的方法。这可以是静态列表（例如公司办公区域范围）或动态列表（例如用户之前认证的IP地址）。
Pros / 优点¶
- Very easy for users.
中文：对用户来说非常简单。 - Requires minimal configuration and management from administrative staff.
中文：需要管理员从配置和管理方面进行最小化操作。
Cons / 缺点¶
- Doesn't provide any protection if the user's system is compromised.
中文：如果用户的系统被入侵，则不提供任何保护。 - Doesn't provide any protection against rogue insiders.
中文：不提供针对恶意内部人员的保护。 - Trusted IP addresses must be carefully restricted (for example, if the open guest Wi-Fi uses the main corporate IP range).
中文：必须谨慎限制可信IP地址（例如，如果开放的访客Wi-Fi使用主企业IP范围）。
Geolocation / 地理位置¶
Rather than using the exact IP address of the user, the geographic location that the IP address is registered to can be used. This is less precise, but may be more feasible to implement in environments where IP addresses are not static. A common usage would be to require additional authentication factors when an authentication attempt is made from outside of the user's normal country.
与其使用用户的精确IP地址，不如使用IP地址注册的地理位置。这不够精确，但在IP地址不静态的环境中可能更容易实现。一种常见的用法是在用户正常国家之外进行身份验证尝试时要求额外的身份验证因素。
Pros / 优点¶
- Very easy for users.
中文：对用户来说非常简单。
Cons / 缺点¶
- Doesn't provide any protection if the user's system is compromised.
中文：如果用户的系统被入侵，则不提供任何保护。 - Doesn't provide any protection against rogue insiders.
中文：不提供针对恶意内部人员的保护。 - Easy for an attacker to bypass by obtaining IP addresses in the trusted country or location.
中文：攻击者很容易通过获取可信国家或位置的IP地址来绕过。 - Privacy features such as Apple's iCloud Private Relay and VPNs can make this less accurate.
中文：隐私功能，如苹果的 iCloud Private Relay 和VPN，可以使这更不准确。
Geofencing / 地理围栏¶
Geofencing is a more precise version of geolocation, which allows the user to define a specific area in which they are allowed to authenticate. This is often used in mobile applications, where the user's location can be determined with a high degree of accuracy using geopositioning hardware like GPS.
地理围栏是地理定位的更精确版本，允许用户定义一个允许他们进行身份验证的特定区域。这通常用于移动应用程序，其中可以使用像GPS这样的地理定位硬件以高精度确定用户的位置。
Pros / 优点¶
- Very easy for users.
中文：对用户来说非常简单。 - Provides a high level of protection against remote attackers.
中文：为远程攻击者提供高级别的保护。
Cons / 缺点¶
- Doesn't provide any protection if the user's system is compromised.
中文：如果用户的系统被入侵，则不提供任何保护。 - Doesn't provide any protection against rogue insiders.
中文：不提供针对恶意内部人员的保护。 - Doesn't provide any protection against attackers who are physically close to the trusted location.
中文：不对物理上接近可信位置的攻击者提供任何保护。
Something You Do / 你所做的¶
Behavioral biometrics, such as keystroke patterns or gait, are a form of "something you are," not a separate authentication factor. Under NIST's biometric requirements, biometric comparison must be combined with an authenticated physical authenticator. General activity signals, such as login times or navigation patterns, can inform risk decisions but do not by themselves constitute MFA.
Behavioral Profiling¶
Behavioral profiling is based on the way the user interacts with the application, such as the time of day they log in, the devices they use, and the way they navigate the application. This is rapidly becoming more common in web applications when combined with Risk Based Authentication and User and Entity Behavior Analytics (UEBA) systems.
Pros / 优点¶
- Doesn't require user interaction.
- Can be used to continuously authenticate the user.
- Combines well with other factors to increase the level of assurance in the user's identity.
Cons / 缺点¶
- Early implementations of behavioral profiling were often inaccurate and caused a significant number of false positives.
- Requires large amounts of data and processing power to analyze the user's behavior.
- May be difficult to implement in environments where the user's behavior is likely to change frequently.
中文：在用户行为可能频繁变化的环境中可能难以实现。
Keystroke & Mouse Dynamics / 按键与鼠标动态¶
Keystroke and mouse dynamics are based on the way the user types and moves their mouse. For example, the time between key presses, the time between key presses and releases, and the speed and acceleration of the mouse. Largely theoretical, and not widely used in practice.
按键与鼠标动态基于用户打字和移动鼠标的方式。例如，按键之间的时间，按键与释放之间的时间，以及鼠标的速度和加速度。主要属于理论范畴，实际应用中并不广泛。
Pros / 优点¶
- Can be used without requiring any additional hardware.
中文：无需任何额外硬件即可使用。 - Can be used without requiring any additional interaction from the user.
中文：无需用户进行任何额外交互即可使用。 - Can be used to continuously authenticate the user.
- Can be used to detect when the user is not the one using the system.
中文：可用于检测用户并非正在使用系统。 - Can be used to detect when the user is under duress.
中文：可用于检测用户是否处于压力之下。 - Can be used to detect when the user is not in a fit state to use the system.
中文：可用于检测用户是否处于适宜使用系统的状态。
Cons / 缺点¶
- Unlikely to be accurate enough to be used as a standalone factor.
中文：不太可能准确到足以作为独立因素使用。 - May be spoofed by AI or other advanced attacks.
中文：可能被AI或其他高级攻击欺骗。
Gait Analysis / 步态分析¶
Gait analysis is based on the way the user walks using cameras and sensors. They are often used in physical security systems, but are not widely used in web applications. Mobile device applications may be able to use the accelerometer to detect the user's gait and use this as an additional factor, however this is still largely theoretical.
步态分析基于用户行走的方式，通过摄像头和传感器进行。它们通常用于物理安全系统，但在Web应用中并不广泛使用。移动设备应用程序可能能够使用加速度计来检测用户的步态，并将其作为额外的因素，然而这仍然主要停留在理论层面。
Pros / 优点¶
- Very difficult to spoof.
中文：很难被欺骗。 - May be used without requiring any additional interaction from the user.
中文：可能无需用户进行任何额外交互即可使用。
Cons / 缺点¶
- Requires specific hardware to implement.
中文：需要特定的硬件来实现。 - Use outside of physical security systems is not widely tested.
中文：在物理安全系统之外的使用尚未广泛测试。
Adaptive or Risk-Based Authentication / 自适应或基于风险的认证¶
Adaptive (or Risk-Based) Authentication adjusts authentication requirements dynamically based on the context of the login attempt. This technique helps improve user experience while strengthening security by applying additional verification steps only when risk is elevated.
自适应（或基于风险）认证根据登录尝试的上下文动态调整认证要求。这种技术有助于改善用户体验，同时通过仅在风险升高时应用额外的验证步骤来加强安全性。
Common signals used to determine risk include:
用于确定风险的常见信号包括：
- Geolocation and IP reputation
中文：地理位置和IP声誉 - Device fingerprinting
中文：设备指纹 - Time of access (e.g., 3 AM login)
中文：访问时间（例如，凌晨3点的登录） - Behavioral biometrics (e.g., typing speed or mouse movements)
中文：行为生物识别（例如，打字速度或鼠标移动） - Known compromised credentials
中文：已知的受损凭证
If risk is detected, the system may:
如果检测到风险，系统可能会：
- Prompt for an additional factor (e.g., OTP)
中文：提示输入额外因素（例如，一次性密码） - Enforce re-authentication
中文：强制重新认证 - Deny access and trigger alerting or account protection flows
中文：拒绝访问并触发警报或账户保护流程
For more details on when to trigger reauthentication after high-risk events—such as account recovery or suspicious activity—see the Reauthentication After Risk Events section in the Authentication Cheat Sheet
有关在高风险事件（如账户恢复或可疑活动）后何时触发重新认证的更多详细信息，请参阅认证速查表的风险事件后的重新认证部分
This method is widely used in modern authentication systems to balance usability and security. However, developers must ensure that risk signals cannot be spoofed and that fallback mechanisms are not weaker than the primary MFA methods.
此方法在现代认证系统中被广泛使用，以平衡可用性和安全性。然而，开发者必须确保风险信号不能被伪造，并且后备机制不比主要的多因素认证方法更弱。
Example Use Case: A user logs in from a trusted device in a usual location — no additional prompt is needed. But if they log in from a new country using a Tor exit node, the system requires SMS verification or triggers an account lock until further verification.
示例用例：用户从受信任的设备在正常位置登录——不需要额外的提示。但如果他们从新的国家使用Tor出口节点登录，系统需要短信验证或触发账户锁定，直到进一步验证。
MFA Attack Patterns and Mitigations / 多因素认证攻击模式和缓解措施¶
Attackers increasingly target weaknesses in MFA deployments and authentication workflows rather than attempting to defeat MFA itself. The following sections describe common attack patterns and recommended mitigations based on guidance from NIST SP 800-63B, CISA's Implementing Phishing-Resistant MFA, the FIDO Alliance Specifications, and OAuth 2.0 Security Best Current Practice (RFC 9700).
攻击者越来越多地针对 MFA 部署和身份验证工作流程中的弱点，而不是试图击败 MFA 本身。以下章节描述了常见的攻击模式和基于 NIST SP 800-63B、CISA 实施抗钓鱼 MFA、FIDO 联盟规范 以及 OAuth 2.0 安全最佳实践（RFC 9700） 的建议的缓解措施。
General Mitigation: Primary Phishing-Resistant Control / 一般缓解：主要抗钓鱼控制¶
Prefer phishing-resistant authenticators (FIDO2/WebAuthn), which bind authentication to the legitimate origin and resist credential theft, MFA fatigue, and reverse-proxy phishing. See the Passkeys section for additional guidance.
优先选择抗钓鱼身份验证器（FIDO2/WebAuthn），将身份验证绑定到合法源头，并抵抗凭证盗窃、MFA 疲劳和反向代理钓鱼。请参阅 Passkeys 部分，以获取更多指导。
MFA Fatigue (Push Notification Bombing) / MFA 疲劳（推送通知轰炸）¶
Attackers repeatedly send MFA push notifications, often combined with social engineering, hoping the user eventually approves one.
攻击者反复发送 MFA 推送通知，通常结合社会工程学，希望用户最终批准其中之一。
Mitigations / 缓解措施¶
- Require challenge-response push authentication (for example, number matching) to prevent blind approval of authentication requests.
中文：要求挑战-响应推送身份验证（例如，数字匹配）以防止盲目批准身份验证请求。 - Rate-limit or cap push notifications to prevent repeated prompt abuse.
中文：限制或限制推送通知，以防止重复提示滥用。 - Monitor for anomalous authentication activity, such as multiple push prompts in a short period or new-device token reuse.
中文：监控异常的认证活动，例如在短时间内出现多次推送提示或新设备令牌重复使用。
Real-Time Phishing Using Reverse Proxies / 使用反向代理进行实时钓鱼¶
Attackers use reverse-proxy phishing frameworks (such as Evilginx, Modlishka, and Muraena) to present convincing copies of legitimate login pages. These frameworks relay authentication traffic between the user and the legitimate service, allowing attackers to capture credentials and session tokens in real-time.
攻击者使用反向代理钓鱼框架（如Evilginx、Modlishka和Muraena）来展示合法登录页面的可信副本。这些框架在用户和合法服务之间中继认证流量，允许攻击者实时捕获凭据和会话令牌。
Mitigations / 缓解措施¶
- Monitor for anomalous authentication and session activity that may indicate credential or session compromise (for example, impossible travel, new ASN, or sudden MFA method changes).
中文：监控可能表明凭据或会话被破坏的异常认证和会话活动（例如，不可能的旅行、新的ASN或突然的多因素认证方法更改）。 - Use phishing-resistant authenticators (see Passkeys section), which bind authentication to the legitimate origin and are resistant to real-time phishing attacks.
中文：使用抗钓鱼认证器（见“密钥”部分），这些认证器将认证绑定到合法源，并能够抵御实时钓鱼攻击。
SIM Swap and Phone Number Takeover / SIM卡交换和电话号码接管¶
Attackers convince a telecommunications provider to transfer a victim's phone number, allowing interception of SMS or voice-based one-time passwords.
攻击者说服电信服务提供商转移受害者的电话号码，允许拦截短信或基于语音的一次性密码。
Mitigations / 缓解措施¶
- Encourage carrier account PINs or port-out protection where available to reduce unauthorized number transfers.
中文：鼓励使用运营商账户PIN码或可用的端口外保护，以减少未经授权的电话号码转移。 - Monitor for unexpected phone-number changes or SIM replacement events.
中文：监控意外的电话号码变更或SIM卡更换事件。 - Prefer phishing-resistant authenticators or TOTP instead of SMS/voice OTP.
中文：优先选择抗钓鱼认证器或TOTP，而不是短信/语音OTP。 - See also: SMS Messages and Phone Calls.
中文：另请参阅：短信消息和电话通话。
Device Binding Bypass / 设备绑定绕过¶
Attackers attempt to bypass device-based authentication by extracting exportable cryptographic keys or replaying cloned device attributes when authenticators are not hardware-protected.
攻击者尝试通过提取可导出的加密密钥或重放克隆的设备属性来绕过基于设备的身份验证，当身份验证器未进行硬件保护时。
Mitigations / 缓解措施¶
- Prefer hardware-backed, non-exportable cryptographic keys (for example, platform authenticators backed by TPM, Secure Enclave, or Android StrongBox).
中文：优先使用基于硬件、不可导出的加密密钥（例如，由TPM、Secure Enclave或Android StrongBox支持的平台身份验证器）。 - Validate authenticator attestation where required by organizational policy.
中文：根据组织政策要求验证身份验证器的声明。
MFA Downgrade Attacks / 多因素认证降级攻击¶
Attackers attempt to force authentication through legacy protocols or authentication flows that do not enforce the same MFA requirements as modern authentication methods. Weak fallback mechanisms or legacy authentication endpoints can allow users to authenticate with lower-assurance factors than intended.
攻击者尝试通过旧版协议或身份验证流程强制进行身份验证，这些协议或流程不强制执行与现代身份验证方法相同的MFA要求。弱回退机制或旧版身份验证端点可能允许用户使用低于预期保证因素进行身份验证。
Mitigations / 缓解措施¶
- Disable legacy authentication protocols and endpoints that cannot enforce MFA consistently.
中文：禁用无法一致执行多因素认证的旧版认证协议和端点。 - Prevent fallback from phishing-resistant authenticators to lower-assurance authentication methods unless required by a documented security policy.
中文：除非有文档化的安全策略要求，否则防止从抗钓鱼认证器回退到较低保证的认证方法。 - Follow OAuth 2.0 Security Best Current Practice (RFC 9700) to prevent OAuth protocol-level downgrade and mix-up attacks.
中文：遵循 OAuth 2.0 安全最佳实践（RFC 9700），以防止 OAuth 协议级别的降级和混淆攻击。
References / 参考¶
- NIST SP 800-63B-4: Authentication and Authenticator Management) （NIST SP 800-63B-4：身份验证和身份验证器管理）
- W3C Web Authentication Level 3) （W3C 网络认证第三级）
- RFC 6238: Time-Based One-Time Password Algorithm) （RFC 6238：基于时间的单次密码算法）