Skip to content

Authentication Cheat Sheet / 身份验证备忘单

Introduction / 介绍

Authentication (AuthN) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim.

身份验证（AuthN）是验证个人、实体或网站是否为所声称的身份的过程，通过确定一个或多个验证者（如密码、指纹或安全令牌）的有效性来支持这一声明。

Digital Identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service but does not necessarily need to be traceable back to a specific real-life subject.

数字身份是在在线交易中参与主体的唯一表示。在数字服务的上下文中，数字身份始终是唯一的，但并不一定需要追溯到特定的现实生活中的主体。

Identity Proofing establishes that a subject is actually who they claim to be. This concept is related to KYC concepts and it aims to bind a digital identity with a real person.

身份验证确立了主体确实是他们所声称的身份。这个概念与KYC（了解你的客户）概念相关，其目的是将数字身份与真实人物绑定。

Session Management is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forth between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict. The Session Management Cheat Sheet contains further guidance on the best practices in this area.

会话管理是服务器维护与它交互的实体状态的过程。这对于服务器记住如何在整个交易过程中对后续请求做出反应是必要的。会话通过会话标识符在服务器上维护，该标识符可以在客户端和服务器之间传递请求时来回传递。会话应针对每个用户是唯一的，并且在计算上非常难以预测。《会话管理作弊表》包含关于该领域最佳实践的进一步指导。

Authentication General Guidelines / 认证通用指南

User IDs / 用户 ID

The primary function of a User ID is to uniquely identify a user within a system. Ideally, User IDs should be randomly generated to prevent the creation of predictable or sequential IDs, which could pose a security risk, especially in systems where User IDs might be exposed or inferred from external sources.

用户ID的主要功能是在系统中唯一标识用户。理想情况下，用户ID应该是随机生成的，以防止创建可预测或顺序的ID，这可能会带来安全风险，尤其是在用户ID可能会暴露或从外部来源推断的系统。

Usernames / 用户名

Usernames are easy-to-remember identifiers chosen by the user and used for identifying themselves when logging into a system or service. The terms User ID and username might be used interchangeably if the username chosen by the user also serves as their unique identifier within the system.

用户名是用户选择的易于记忆的标识符，用于在登录系统或服务时识别自己。如果用户选择的用户名也用作其在系统内的唯一标识符，则术语“用户 ID”和“用户名”可以互换使用。

Users should be permitted to use their email address as a username, provided the email is verified during sign-up. Additionally, they should have the option to choose a username other than an email address. For information on validating email addresses, please visit the input validation cheat sheet email discussion.

用户应允许使用他们的电子邮件地址作为用户名，前提是在注册期间验证了电子邮件。此外，他们应有权选择除电子邮件地址以外的用户名。有关验证电子邮件地址的信息，请访问输入验证作弊表电子邮件讨论。

Authentication Solution and Sensitive Accounts / 身份验证解决方案和敏感帐户

  • Do NOT allow login with sensitive accounts (i.e. accounts that can be used internally within the solution such as to a backend / middleware / database) to any front-end user interface
    中文：绝对不允许使用敏感账户（即可以在解决方案内部使用的账户，例如后端/中间件/数据库）登录任何前端用户界面
  • Do NOT use the same authentication solution (e.g. IDP / AD) used internally for unsecured access (e.g., public access / DMZ)
    中文：切勿使用与内部未加密访问（例如，公共访问/DMZ）相同的身份验证解决方案（例如，IDP / AD）

Implement Proper Password Strength Controls / 实施适当的密码强度控制

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password through either manual or automated means. The following characteristics define a strong password:

使用密码进行身份验证时的一个主要关注点是密码强度。一个“强大”的密码策略使得通过手动或自动化手段猜测密码变得困难或几乎不可能。以下特征定义了强大的密码：

  • Password Length
    中文：密码长度
    • Minimum length for passwords should be enforced by the application.
      中文：最小密码长度应由应用程序强制执行。
      • If MFA is enabled passwords shorter than 8 characters are considered to be weak (NIST SP800-63B).
        中文：如果启用了多因素认证（MFA），则长度短于8个字符的密码被视为弱密码（NIST SP800-63B）。
      • If MFA is not enabled passwords shorter than 15 characters are considered to be weak (NIST SP800-63B).
        中文：如果未启用多因素认证（MFA），则长度短于15个字符的密码被视为弱密码（NIST SP800-63B）。
    • Maximum password length should be at least 64 characters to allow passphrases (NIST SP800-63B). Note that certain implementations of hashing algorithms may cause long password denial of service.
      中文：最大密码长度应至少为64个字符，以允许使用口令短语（NIST SP800-63B）。请注意，某些哈希算法的实现可能会导致长密码拒绝服务。
    • Longer passphrases are effective because they raise the number of guesses an attacker's dictionary or wordlist has to cover, not because of a precise entropy value: NIST notes that "estimating entropy for user-chosen passwords is challenging" and recommends length and blocklist checks (see below) over composition or entropy math (NIST SP800-63B, Strength of Passwords). Entropy estimates rely on assumptions about the search space and should be treated as illustrative rather than as absolute measures of password strength.
      中文：较长的口令短语有效，因为它们增加了攻击者字典或单词列表中必须覆盖的猜测次数，而不是因为精确的熵值：NIST指出，"估计用户选择密码的熵值具有挑战性"，并建议长度和黑名单检查（见下文）而不是组成或熵数学（NIST SP800-63B，密码强度）。熵估计依赖于对搜索空间的假设，应被视为说明性的，而不是作为密码强度绝对措施的依据。
    • Attackers commonly use password guessing techniques that leverage common-password dictionaries and password lists, and may use previously compromised credentials in credential stuffing attacks. These behaviors are reflected in MITRE ATT&CK T1110 – Brute Force, including Password Guessing, Password Spraying, and Credential Stuffing. Screening passwords against blocklists helps prevent users from selecting passwords that are commonly used or already known to attackers, as recommended by NIST SP 800-63B – Passwords.
      中文：攻击者通常使用利用常见密码字典和密码列表的密码猜测技术，并可能在凭证填充攻击中使用先前泄露的凭证。这些行为反映在MITRE ATT&CK T1110 – 爆破中，包括密码猜测、密码喷射和凭证填充。通过黑名单筛选密码有助于防止用户选择常用或已知被攻击者使用的密码，如NIST SP 800-63B – 密码所建议的。
  • Do not silently truncate passwords. The Password Storage Cheat Sheet provides further guidance on how to handle passwords that are longer than the maximum length.
    中文：不要默默地截断密码。 密码存储备忘单 提供了有关如何处理超过最大长度的密码的进一步指导。
  • Allow usage of all characters including unicode and whitespace. There should be no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.
    中文：允许使用 所有 字符，包括 unicode 和空格。不应存在​​限制允许的字符类型的密码组合规则。不应有大小写、数字或特殊字符的要求。
  • Ensure credential rotation when a password leak occurs, at the time of compromise identification or when authenticator technology changes. Avoid requiring periodic password changes; instead, encourage users to pick strong passwords and enable Multifactor Authentication Cheat Sheet (MFA). According to NIST guidelines, verifiers should not mandate arbitrary password changes (e.g., periodically).
    中文：确保在发生密码泄露、识别泄露或身份验证器技术发生变化时进行凭证轮换。避免要求定期更改密码；相反，鼓励用户选择强密码并启用多重身份验证备忘单 (MFA)。根据 NIST 指南，验证者不应强制任意更改密码（例如定期更改）。
  • Include a password strength meter to help users create a more complex password
    中文：包含密码强度计以帮助用户创建更复杂的密码
    • zxcvbn-ts library can be used for this purpose.
    • Other language implementations of zxcvbn listed here; however check the age and maturity of each example before use.
      中文：zxcvbn的其他语言实现在此处列出；然而，在使用之前请检查每个示例的年龄和成熟度。
  • Block common and previously breached passwords
    中文：阻止常见和之前被破解的密码
    • Pwned Passwords) （破解密码） is a service where passwords can be checked against previously breached passwords. Details on the API are here.
    • Alternatively, you can download the Pwned Passwords database using this mechanism to host it yourself.
      中文：或者，您可以通过此机制 下载 Pwned Passwords 数据库 以自行托管。
    • Other top password lists are available but there is no guarantee as to how updated they are:
      中文：其他顶级密码列表也可用，但不能保证它们的更新程度：

For more detailed information check / 欲了解更详细的信息请查看

Implement Secure Password Recovery Mechanism / 实施安全密码恢复机制

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see Forgot Password Cheat Sheet for details on this feature.

应用程序通常具有一种机制，可以为用户提供一种在忘记密码时访问其帐户的方法。有关此功能的详细信息，请参阅忘记密码备忘单。

Store Passwords in a Secure Fashion / 以安全的方式存储密码

It is critical for an application to store a password using the right cryptographic technique. Please see Password Storage Cheat Sheet for details on this feature.

对于应用程序来说，使用正确的加密技术存储密码至关重要。有关此功能的详细信息，请参阅密码存储备忘单。

Compare Password Hashes Using Safe Functions / 使用安全函数比较密码散列

Where possible, the user-supplied password should be compared to the stored password hash using a secure password comparison function provided by the language or framework, such as the password_verify() function in PHP. Where this is not possible, ensure that the comparison function:

如果可能，应使用语言或框架提供的安全密码比较函数（例如 PHP 中的 password_verify() 函数）将用户提供的密码与存储的密码哈希进行比较。如果不可能，请确保比较函数：

  • Has a maximum input length, to protect against denial of service attacks with very long inputs.
    中文：具有最大输入长度，以防止输入很长的拒绝服务攻击。
  • Explicitly sets the type of both variables, to protect against type confusion attacks such as Magic Hashes in PHP.
    中文：显式设置两个变量的类型，以防止如 PHP 中的魔法哈希等类型混淆攻击。
  • Returns in constant time, to protect against timing attacks.
    中文：以恒定时间返回，以防止时间攻击。

Change Password Feature / 更改密码功能

When developing a change password feature, ensure to have:

在开发更改密码功能时，请确保以下内容：

  • The user is authenticated with an active session.
    中文：用户通过活动会话进行身份验证。
  • Current password verification. This is to ensure that it's the legitimate user who is changing the password. Consider this abuse case: a user logs in on a public computer and forgets to log out. Another person could then use that active session. If we don't verify the current password, this other person may be able to change the password.
    中文：当前密码验证。这是为了确保更改密码的是合法用户。考虑以下滥用案例：用户登录公共计算机并忘记注销。然后另一个人可以使用该活动会话。如果我们不验证当前密码，其他人可能可以更改密码。

Transmit Passwords Only Over TLS or Other Strong Transport / 仅通过 TLS 或其他强传输传输密码

See: Transport Layer Security Cheat Sheet

请参阅：传输层安全备忘单

The login page and all subsequent authenticated pages must be exclusively accessed over TLS or other strong transport. Failure to utilize TLS or other strong transport for the login page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS or other strong transport for authenticated pages after login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.

登录页面和所有后续的身份验证页面必须通过 TLS 或其他强传输进行独占访问。如果登录页面未能使用 TLS 或其他强大的传输，攻击者就可以修改登录表单操作，从而导致用户的凭据被发布到任意位置。如果登录后未能对经过身份验证的页面使用 TLS 或其他强传输，攻击者就可以查看未加密的会话 ID 并危及用户的经过身份验证的会话。

Require Re-authentication for Sensitive Features / 需要对敏感功能重新进行身份验证

In order to mitigate CSRF and session hijacking, it's important to require the current credentials for an account before updating sensitive account information such as the user's password or email address -- or before sensitive transactions, such as shipping a purchase to a new address. Without this countermeasure, an attacker may be able to execute sensitive transactions through a CSRF or XSS attack without needing to know the user's current credentials. Additionally, an attacker may get temporary physical access to a user's browser or steal their session ID to take over the user's session.

为了减轻 CSRF 和会话劫持，在更新敏感帐户信息（例如用户密码或电子邮件地址）之前，或者在敏感交易（例如将购买的商品运送到新地址）之前，需要提供帐户的当前凭据，这一点非常重要。如果没有这种对策，攻击者可能能够通过 CSRF 或 XSS 攻击执行敏感交易，而无需知道用户当前的凭据。此外，攻击者可能会获得对用户浏览器的临时物理访问权限或窃取其会话 ID 来接管用户的会话。

Re-authentication After Risk Events / 风险事件后的重新认证

Overview: Re-authentication is critical when an account has experienced high-risk activity such as account recovery, password resets, or suspicious behavior patterns. This section outlines when and how to trigger re-authentication to protect users and prevent unauthorized access. For further details, see the Require Re-authentication for Sensitive Features section.

概述： 当帐户经历了帐户恢复、密码重置或可疑行为模式等高风险活动时，重新身份验证至关重要。本节概述了何时以及如何触发重新身份验证以保护用户并防止未经授权的访问。有关更多详细信息，请参阅敏感功能需要重新身份验证部分。

When to Trigger Re-authentication / 何时触发重新认证

  • Suspicious Account Activity When unusual login patterns, IP address changes, or device enrollments occur
    中文：可疑账户活动 当出现不寻常的登录模式、IP 地址变更或设备注册时
  • Account Recovery After users reset their passwords or change sensitive account details
    中文：账户恢复 用户重置密码或更改敏感账户信息后
  • Critical Actions For high-risk actions like changing payment details or adding new trusted devices
    中文：关键操作 对于更改支付详情或添加新受信任设备等高风险操作

Re-authentication Mechanisms / 重新认证机制

  • Adaptive Authentication Use risk-based authentication models that adapt to the user's behavior and context
    中文：自适应认证 使用基于风险的认证模型，以适应用户的行为和上下文
  • Multi-Factor Authentication (MFA) Require an additional layer of verification for sensitive actions or events
    中文：多因素认证 (MFA) 对于敏感操作或事件，要求额外的验证层
  • Bound Authenticators Require an authenticator already bound to the account, such as the current password or a passkey. Do not substitute security questions, which are excluded by ASVS 6.4.2.
    中文：绑定认证器 需要一个已经绑定到账户的认证器，例如当前密码或通行证。不要使用安全问题，这些问题已被 ASVS 6.4.2 排除。

Implementation Recommendations / 实施建议

  • Minimize User Friction Ensure that re-authentication does not disrupt the user experience unnecessarily
    中文：最小化用户摩擦 确保重新认证不会不必要地干扰用户体验
  • Context-Aware Decisions Make re-authentication decisions based on context (e.g., geolocation, device type, prior patterns)
    中文：上下文感知决策 根据上下文（例如地理位置、设备类型、先前模式）做出重新认证决策
  • Secure Session Management Invalidate sessions after re-authentication and rotate tokens—see the OWASP Session Management Cheat Sheet
    中文：安全会话管理 重新认证后使会话无效并轮换令牌——参见 OWASP 会话管理备忘单

Consider Strong Transaction Authentication / 考虑强交易认证

Some applications should use a second factor to check whether a user may perform sensitive operations. For more information, see the Transaction Authorization Cheat Sheet.

某些应用程序应使用第二个因素来检查用户是否可以执行敏感操作。更多信息，请参阅 交易授权备忘单。

TLS Client Authentication / TLS 客户端身份验证

TLS Client Authentication, also known as two-way TLS authentication, consists of both browser and server sending their respective TLS certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a verifiably-valid Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third-party CA or its own CA. To do this, the server must provide the user with a certificate generated specifically for him, assigning values to the subject so that these can be used to determine what user the certificate should validate. The user installs the certificate on a browser and now uses it for the website.

TLS 客户端身份验证，也称为双向 TLS 身份验证，由浏览器和服务器在 TLS 握手过程中发送各自的 TLS 证书组成。正如您可以通过使用证书并向可验证有效的证书颁发机构 (CA) 询问证书是否有效来验证服务器的真实性一样，服务器也可以通过从客户端接收证书并根据第三方 CA 或其自己的 CA 进行验证来对用户进行身份验证。为此，服务器必须向用户提供专门为其生成的证书，并为主题分配值，以便可以使用这些值来确定证书应验证哪些用户。用户在浏览器上安装证书，现在将其用于网站。

This approach is appropriate when:

此方法适用于以下情况：

  • It is acceptable (or even preferred) that the user has access to the website only from a single computer/browser.
    中文：用户只能从单个计算机/浏览器访问网站是可以接受的（甚至更受欢迎的）。
  • The user is not easily scared by the process of installing TLS certificates on their browser, or there will be someone, probably from IT support, who will do this for the user.
    中文：用户不会被在浏览器上安装TLS证书的过程轻易吓到，或者会有某人，可能是来自IT支持的人员，为用户完成这项操作。
  • The website requires an extra step of security.
    中文：该网站需要额外的安全措施。
  • It is also a good thing to use when the website is for an intranet of a company or organization.
    中文：当网站用于公司或组织的内部网时，使用它也是一个好东西。

It is generally not a good idea to use this method for widely and publicly available websites that will have an average user. For example, it wouldn't be a good idea to implement this for a website like Facebook. While this technique can prevent the user from having to type a password (thus protecting against an average keylogger from stealing it), it is still considered a good idea to consider using both a password and TLS client authentication combined.

对于拥有普通用户的广泛公开的网站来说，使用此方法通常不是一个好主意。例如，对于 Facebook 这样的网站来说，实现这一点并不是一个好主意。虽然这种技术可以防止用户必须输入密码（从而防止普通键盘记录器窃取密码），但考虑结合使用密码和 TLS 客户端身份验证仍然被认为是一个好主意。

Additionally, if the client is behind an enterprise proxy that performs SSL/TLS decryption, this will break certificate authentication unless the site is allowed on the proxy.

此外，如果客户端位于执行 SSL/TLS 解密的企业代理后面，这将破坏证书身份验证，除非代理允许该站点。

For more information, see: Client-authenticated TLS handshake

有关更多信息，请参阅：客户端验证的 TLS 握手

Authentication and Error Messages / 身份验证和错误消息

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.

在身份验证功能的情况下，错误实现的错误消息可用于用户 ID 和密码枚举的目的。应用程序应该以通用方式响应（HTTP 和 HTML）。

Authentication Responses / 认证响应

Using any of the authentication mechanisms (login, password reset, or password recovery), an application must respond with a generic error message regardless of whether:

使用任何身份验证机制（登录、密码重置或密码恢复），应用程序都必须使用通用错误消息进行响应，无论是否：

  • The user ID or password was incorrect.
    中文：用户ID或密码不正确。
  • The account does not exist.
    中文：该帐户不存在。
  • The account is locked or disabled.
    中文：该帐户已被锁定或禁用。

The account registration feature should also be taken into consideration, and the same approach of a generic error message can be applied regarding the case in which the user exists.

还应考虑账户注册功能，并且可以采用通用的错误消息方法来处理用户已存在的情况。

The objective is to prevent the creation of a discrepancy factor, allowing an attacker to mount a user enumeration action against the application.

目的是防止创建差异因素，从而允许攻击者针对应用程序安装用户枚举操作。

It is interesting to note that the business logic itself can bring a discrepancy factor related to the processing time taken. Indeed, depending on the implementation, the processing time can be significantly different according to the case (success vs failure) allowing an attacker to mount a time-based attack (delta of some seconds for example).

值得注意的是，业务逻辑本身可能会因为处理时间而带来差异因素。确实，根据实现方式，处理时间可能会根据情况（成功与失败）显著不同，从而允许攻击者发起基于时间的攻击（例如几秒钟的差值）。

Example using pseudo-code for a login feature:

使用伪代码实现登录功能的示例：

  • First implementation using the "quick exit" approach
    中文：首次使用“快速退出”方法实现
IF USER_EXISTS(username) THEN
    password_hash=HASH(password)
    IS_VALID=LOOKUP_CREDENTIALS_IN_STORE(username, password_hash)
    IF NOT IS_VALID THEN
        RETURN Error("Invalid Username or Password!")
    ENDIF
ELSE
   RETURN Error("Invalid Username or Password!")
ENDIF

It can be clearly seen that if the user doesn't exist, the application will directly throw an error. Otherwise, when the user exists and the password doesn't, it is apparent that there will be more processing before the application errors out. In return, the response time will be different for the same error, allowing the attacker to differentiate between a wrong username and a wrong password.

可以明显看出，如果用户不存在，应用程序会直接抛出错误。否则，当用户存在而密码不存在时，显然在应用程序出错之前将进行更多处理。作为回报，同一错误的响应时间会有所不同，从而使攻击者能够区分错误的用户名和错误的密码。

  • Second implementation without relying on the "quick exit" approach:
    中文：第二个不依赖于“快速退出”方法的实现：
password_hash=HASH(password)
IS_VALID=LOOKUP_CREDENTIALS_IN_STORE(username, password_hash)
IF NOT IS_VALID THEN
   RETURN Error("Invalid Username or Password!")
ENDIF

This code will go through the same process no matter what the user or the password is, allowing the application to return in approximately the same response time.

无论用户或密码是什么，此代码都将经历相同的过程，从而允许应用程序在大约相同的响应时间内返回。

The problem with returning a generic error message for the user is a User Experience (UX) matter. A legitimate user might feel confused with the generic messages, thus making it hard for them to use the application, and might after several retries, leave the application because of its complexity. The decision to return a generic error message can be determined based on the criticality of the application and its data. For example, for critical applications, the team can decide that under the failure scenario, a user will always be redirected to the support page and a generic error message will be returned.

向用户返回通用错误消息的问题是用户体验 (UX) 问题。合法用户可能会对通用消息感到困惑，从而使他们难以使用该应用程序，并且可能在多次重试后，由于其复杂性而离开该应用程序。返回“通用错误消息”的决定可以根据应用程序及其数据的重要性来确定。例如，对于关键应用程序，团队可以决定在故障情况下，用户将始终被重定向到支持页面，并返回通用错误消息。

Regarding the user enumeration itself, protection against brute-force attacks is also effective because it prevents an attacker from applying the enumeration at scale. Usage of CAPTCHA can be applied to a feature for which a generic error message cannot be returned because the user experience must be preserved.

关于用户枚举本身，针对暴力攻击的保护也很有效，因为它可以防止攻击者大规模应用枚举。 CAPTCHA 的使用可应用于无法返回“通用错误消息”的功能，因为必须保留“用户体验”。

Incorrect and correct response examples / 错误和正确反应示例
Login / 登录

Incorrect response examples:

不正确的响应示例：

  • "Login for User foo: invalid password."
    中文：“用户foo的登录：密码无效。”
  • "Login failed, invalid user ID."
    中文：“登录失败，用户 ID 无效。”
  • "Login failed; account disabled."
  • "Login failed; this user is not active."

Correct response example:

  • "Login failed; Invalid user ID or password."
Password recovery / 密码恢复

Incorrect response examples:

不正确的响应示例：

  • "We just sent you a password reset link."
    中文：“我们刚刚向您发送了密码重置链接。”
  • "This email address doesn't exist in our database."

Correct response example:

  • "If that email address is in our database, we will send you an email to reset your password."
    中文：“如果该电子邮件地址在我们的数据库中，我们将向您发送一封电子邮件以重置您的密码。”
Account creation / 账户创建

Incorrect response examples:

不正确的响应示例：

  • "This user ID is already in use."
    中文：“该用户ID已被使用。”
  • "Welcome! You have signed up successfully."

Correct response example:

  • "A link to activate your account has been emailed to the address provided."
    中文：“激活您帐户的链接已通过电子邮件发送到所提供的地址。”
Error Codes and URLs / 错误代码和 URL

The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can leak information about whether the account is valid or not.

根据身份验证尝试响应，应用程序可能会返回不同的 HTTP 错误代码。对于阳性结果，它可能会响应 200，对于阴性结果，可能会响应 403。即使向用户显示通用错误页面，HTTP 响应代码也可能不同，这可能会泄漏有关帐户是否有效的信息。

Error disclosure can also be used as a discrepancy factor, consult the error handling cheat sheet regarding the global handling of different errors in an application.

错误披露也可以用作差异因素，请参阅有关应用程序中不同错误的全局处理的错误处理备忘单。

Protect Against Automated Attacks / 保护免受自动化攻击

There are a number of different types of automated attacks that attackers can use to try and compromise user accounts. The most common types are listed below:

Attack Type / 攻击类型 Description / 描述
Brute Force
暴力破解		 Testing multiple passwords from a dictionary or other source against a single account.
从字典或其他来源测试多个密码对单个账户的匹配。
Credential Stuffing
凭证填充		 Testing username/password pairs obtained from the breach of another site.
测试从其他网站泄露中获得的用户名/密码对。
Password Spraying
密码喷洒		 Testing a single weak password against a large number of different accounts.
对大量不同账户测试单个弱密码。

Different protection mechanisms can be implemented to protect against these attacks. In many cases, these defenses do not provide complete protection, but when a number of them are implemented in a defense-in-depth approach, a reasonable level of protection can be achieved.

可以实施不同的保护机制来防御这些攻击。在许多情况下，这些防御措施不能提供完全的保护，但当采用深度防御策略实施多个防御措施时，可以达到合理的保护水平。

The following sections will focus primarily on preventing brute-force attacks, although these controls can also be effective against other types of attacks. For further guidance on defending against credential stuffing and password spraying, see the Credential Stuffing Cheat Sheet.

以下各节将主要关注防止暴力攻击，尽管这些控制也可以有效地抵御其他类型的攻击。有关防御凭据填充和密码喷洒的进一步指导，请参阅凭据填充备忘单。

Multi-Factor Authentication / 多因素身份验证

Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including brute-force attacks, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises. As such, it should be implemented wherever possible; however, depending on the audience of the application, it may not be practical or feasible to enforce the use of MFA.

多重身份验证 (MFA) 是迄今为止针对大多数与密码相关的攻击（包括暴力攻击）的最佳防御方法，Microsoft 的分析表明，它可以阻止 99.9% 的帐户泄露。因此，应尽可能实施；但是，根据应用程序的受众，强制使用 MFA 可能不实际或不可行。

The Multifactor Authentication Cheat Sheet contains further guidance on implementing MFA.

《多因素认证速查表》（Multifactor Authentication Cheat Sheet）包含了关于实施多因素认证的进一步指导。

Login Throttling / 登录限制

Login Throttling is a security mechanism used to prevent an attacker from making too many attempts at guessing a password through normal interactive means, it includes the following controls:

登录限制是一种安全机制，用于防止攻击者通过正常交互方式尝试猜测密码的次数过多，它包括以下控制措施：

  • Maximum number of attempts.
    中文：最大尝试次数。
Account Lockout / 账户锁定

The most common protection against these attacks is to implement account lockout, which prevents any more login attempts for a period after a certain number of failed logins.

针对这些攻击的最常见的保护措施是实施帐户锁定，这可以在一定次数的登录失败后的一段时间内防止再次尝试登录。

The counter of failed logins should be associated with the account itself, rather than the source IP address, in order to prevent an attacker from making login attempts from a large number of different IP addresses. There are a number of different factors that should be considered when implementing an account lockout policy in order to find a balance between security and usability:

登录失败的计数器应该与帐户本身相关联，而不是与源IP地址相关联，以防止攻击者从大量不同的IP地址进行登录尝试。实施帐户锁定策略时应考虑许多不同的因素，以便在安全性和可用性之间找到平衡：

  • The number of failed attempts before the account is locked out (lockout threshold).
    中文：在账户被锁定之前失败尝试的次数（锁定阈值）。
  • The time period that these attempts must occur within (observation window).
    中文：这些尝试必须发生的时间段（观察窗口）。
  • How long the account is locked out for (lockout duration).
    中文：账户被锁定的持续时间（锁定时长）。

Rather than implementing a fixed lockout duration (e.g., ten minutes), some applications use an exponential lockout, where the lockout duration starts as a very short period (e.g., one second), but doubles after each failed login attempt.

而不是实施固定的锁定时长（例如，十分钟），一些应用程序使用指数锁定，其中锁定时长从一个非常短的周期开始（例如，一秒），但在每次失败的登录尝试后加倍。

  • Amount of time to delay after each account lockout (max 2-3, after that permanent account lockout).
    中文：每次帐户锁定后的延迟时间（永久帐户锁定后最多 2-3 时间）。

When designing an account lockout system, care must be taken to prevent it from being used to cause a denial of service by locking out other users' accounts. One way this could be performed is to allow the use of the forgotten password functionality to log in, even if the account is locked out.

在设计帐户锁定系统时，必须注意防止它被用来通过锁定其他用户的帐户来导致拒绝服务。执行此操作的一种方法是允许使用忘记密码功能进行登录，即使帐户被锁定也是如此。

CAPTCHA

The use of an effective CAPTCHA can help to prevent automated login attempts against accounts. However, many CAPTCHA implementations have weaknesses that allow them to be solved using automated techniques or can be outsourced to services that can solve them. As such, the use of CAPTCHA should be viewed as a defense-in-depth control to make brute-force attacks more time-consuming and expensive, rather than as a preventative.

使用有效的验证码有助于防止针对帐户的自动登录尝试。然而，许多验证码实现都存在弱点，这些弱点允许使用自动化技术来解决，或者可以外包给可以解决这些问题的服务。因此，验证码的使用应被视为一种深度防御控制，以使暴力攻击更加耗时和昂贵，而不是一种预防措施。

It may be more user-friendly to only require a CAPTCHA be solved after a small number of failed login attempts, rather than requiring it from the very first login.

仅在少量登录尝试失败后才需要验证码，而不是从第一次登录时就要求输入验证码，这可能对用户更友好。

Security Questions and Memorable Words / 安全问题和难忘的单词

Do not use security questions for authentication or re-authentication; ASVS 6.4.2 excludes knowledge-based authentication. When verifying a password or memorable word, request and verify the full secret rather than selected characters, as required by NIST SP 800-63B-4. See the Choosing and Using Security Questions Cheat Sheet for guidance limited to legacy systems.

不要使用安全问题进行身份验证或重新身份验证；ASVS 6.4.2 排除了基于知识的身份验证。在验证密码或记忆词时，请求并验证完整密钥，而不是所选字符，如NIST SP 800-63B-4所要求的。有关针对旧系统的指导，请参阅选择和使用安全问题速查表。

Logging and Monitoring / 记录和监控

Enable logging and monitoring of authentication functions to detect attacks/failures on a real-time basis

启用身份验证功能的日志记录和监控，以实时检测攻击/故障

  • Ensure that all failures are logged and reviewed
    中文：确保所有故障都被记录并审查
  • Ensure that all password failures are logged and reviewed
    中文：确保记录并审查所有密码失败
  • Ensure that all account lockouts are logged and reviewed
    中文：确保所有帐户锁定均已记录并进行审查

Use of authentication protocols that require no password / 使用无需密码的认证协议

While authentication through a combination of username, password, and multi-factor authentication is considered generally secure, there are use cases where it isn't considered the best option or even safe. Examples of this are third-party applications that desire to connect to the web application, either from a mobile device, another website, desktop, or other situations. When this happens, it is NOT considered safe to allow the third-party application to store the user/password combo, since then it extends the attack surface into their hands, where it isn't in your control. For this and other use cases, there are several authentication protocols that can protect you from exposing your users' data to attackers.

虽然通过用户名、密码和多因素身份验证组合进行的身份验证通常被认为是安全的，但在某些用例中，它不被认为是最佳选择，甚至不安全。此类示例包括希望从移动设备、另一个网站、桌面或其他情况连接到 Web 应用程序的第三方应用程序。发生这种情况时，允许第三方应用程序存储用户/密码组合被认为是不安全的，因为这样会将攻击面扩展到他们的手中，而不受您的控制。对于此用例和其他用例，有多种身份验证协议可以保护您免遭攻击者泄露用户数据。

OAuth 2.0 and 2.1 / OAuth 2.0 和 2.1

OAuth is an authorization framework for delegated access to APIs. See also: OAuth 2.0 Cheat Sheet.

OAuth 是一个用于委托访问 API 的授权框架。另请参阅：OAuth 2.0 备忘单。

Note: OAuth 2.1 is an active IETF Working Group draft that consolidates OAuth 2.0 and widely adopted best practices and is intended to replace RFC 6749/6750; guidance in this cheat sheet applies to both OAuth 2.0 and OAuth 2.1. Because Internet-Drafts are revisioned, use the unversioned OAuth 2.1 Datatracker page for the current draft. See also oauth.net/2.1.

中文：注意： OAuth 2.1 是一个活跃的 IETF 工作组草案，它整合了 OAuth 2.0 和广泛采用的最佳实践，旨在取代 RFC 6749/6750；本速查表中的指南适用于 OAuth 2.0 和 OAuth 2.1。由于 Internet-Drafts 是修订版的，请使用 未版本化的 OAuth 2.1 数据跟踪页面 获取当前草案。另请参阅 oauth.net/2.1。

OpenID Connect (OIDC) / OpenID 连接 (OIDC)

OpenID Connect 1.0 (OIDC) is an identity layer on top of OAuth. It defines how a client (relying party) verifies the end user's identity using an ID Token (a signed JWT) and how to obtain user claims in an interoperable way. Use OIDC for authentication/SSO; use OAuth for authorization to APIs.

OpenID Connect 1.0 (OIDC) 是建立在 OAuth 之上的一个身份层。它定义了客户端（依赖方）如何使用 ID Token（一个签名JWT）验证最终用户的身份，以及如何以互操作的方式获取用户声明。使用 OIDC 进行身份验证/SSO；使用 OAuth 进行API的授权。

OIDC implementation guidance / OIDC 实施指南

  • Validate ID Tokens on the relying party: issuer (iss), audience (aud), signature (per provider JWKs), expiration (exp).
    中文：在依赖方上验证 ID 令牌：发行者 (iss)、受众 (aud)、签名（每个提供者 JWK）、过期 (exp)。
  • Prefer well-maintained libraries/SDKs and provider discovery/JWKS endpoints.
    中文：优先使用 维护良好的库/SDK 和提供者发现/JWKS 端点。
  • Use the UserInfo endpoint when additional claims beyond the ID Token are required.
    中文：当需要 ID 令牌之外的其他声明时，请使用 UserInfo 端点。

Avoid confusion: OpenID 2.0 ("OpenID") was a separate, legacy authentication protocol that has been superseded by OpenID Connect and is considered obsolete. New systems should not implement OpenID 2.0. References: OpenID Foundation — obsolete OpenID 2.0 libraries, OpenID 2.0 → OIDC migration

中文：避免混淆： OpenID 2.0（"OpenID"） 是一个独立的、过时的认证协议，已被 OpenID Connect 取代，并被认为是过时的。新系统不应实现 OpenID 2.0。参考资料：OpenID 基金会 — 过时的 OpenID 2.0 库，OpenID 2.0 → OIDC 迁移

Secure Federated Account Linking / 安全联合帐户链接

When linking an OIDC identity to an existing application account:

将 OIDC 身份链接到现有应用程序帐户时：

SAML

Security Assertion Markup Language (SAML) is often considered to compete with OpenId. The most recommended version is 2.0 since it is very feature-complete and provides strong security. Like OpenId, SAML uses identity providers, but unlike OpenId, it is XML-based and provides more flexibility. SAML is based on browser redirects which send XML data. Furthermore, SAML isn't only initiated by a service provider; it can also be initiated from the identity provider. This allows the user to navigate through different portals while still being authenticated without having to do anything, making the process transparent.

安全断言标记语言 (SAML) 通常被认为与 OpenId 竞争。最推荐的版本是 2.0，因为它功能非常齐全并且提供了强大的安全性。与 OpenId 一样，SAML 使用身份提供程序，但与 OpenId 不同的是，它基于 XML，并提供更大的灵活性。 SAML 基于发送 XML 数据的浏览器重定向。此外，SAML 不仅由服务提供商发起，而且还由服务提供商发起。它也可以从身份提供者发起。这允许用户浏览不同的门户，同时仍然进行身份验证，而无需执行任何操作，从而使过程透明。

While OpenId has taken most of the consumer market, SAML is often the choice for enterprise applications because there are few OpenId identity providers which are considered enterprise-class (meaning that the way they validate the user identity doesn't have high standards required for enterprise identity). It is more common to see SAML being used inside of intranet websites, sometimes even using a server from the intranet as the identity provider.

虽然OpenId占据了大部分消费者市场，但SAML通常是企业应用程序的选择，因为很少有OpenId身份提供者被认为是企业级的（这意味着它们验证用户身份的方式不符合企业身份所需的高标准）。在内部网站中更常见的是使用SAML，有时甚至使用内部网络中的服务器作为身份提供者。

In the past few years, applications like SAP ERP and SharePoint (SharePoint by using Active Directory Federation Services 2.0) have decided to use SAML 2.0 authentication as an often preferred method for single sign-on implementations whenever enterprise federation is required for web services and web applications.

在过去几年中，每当 Web 服务和 Web 应用程序需要企业联合时，SAP ERP 和 SharePoint（使用 Active Directory 联合身份验证服务 2.0 的 SharePoint）等应用程序已决定使用 SAML 2.0 身份验证作为单点登录实施的首选方法。

See also: SAML Security Cheat Sheet

另请参阅：SAML 安全备忘单

FIDO

The Fast Identity Online (FIDO) Alliance has created two protocols to facilitate online authentication: the Universal Authentication Framework (UAF) protocol and the Universal Second Factor (U2F) protocol. While UAF focuses on passwordless authentication, U2F allows the addition of a second factor to existing password-based authentication. Both protocols are based on a public key cryptography challenge-response model.

快速身份在线 (FIDO) 联盟创建了两种协议来促进在线身份验证：通用身份验证框架 (UAF) 协议和通用第二因素 (U2F) 协议。 UAF 专注于无密码身份验证，而 U2F 允许在现有的基于密码的身份验证中添加第二个因素。这两种协议都基于公钥加密挑战-响应模型。

UAF takes advantage of existing security technologies present on devices for authentication including fingerprint sensors, cameras (face biometrics), microphones (voice biometrics), Trusted Execution Environments (TEEs), Secure Elements (SEs), and others. The protocol is designed to plug these device capabilities into a common authentication framework. UAF works with both native applications and web applications.

UAF利用设备上现有的安全技术进行身份验证，包括指纹传感器、摄像头（面部生物识别）、麦克风（声音生物识别）、可信执行环境（TEEs）、安全元素（SEs）等。该协议旨在将这些设备功能插入到通用的身份验证框架中。UAF与原生应用程序和Web应用程序都兼容。

U2F augments password-based authentication using a hardware token (typically USB) that stores cryptographic authentication keys and uses them for signing. The user can use the same token as a second factor for multiple applications. U2F works with web applications. It provides protection against phishing by using the URL of the website to look up the stored authentication key.

U2F 使用硬件令牌（通常是 USB）增强基于密码的身份验证，该硬件令牌存储加密身份验证密钥并使用它们进行签名。用户可以使用相同的令牌作为多个应用程序的第二因素。 U2F 可与 Web 应用程序配合使用。它通过使用网站的 URL 查找存储的身份验证密钥来提供针对网络钓鱼的保护。

FIDO2: FIDO2 combines WebAuthn with the Client-to-Authenticator Protocols (CTAP). U2F is now named CTAP1; UAF is a separate protocol. WebAuthn credentials form the foundation of modern Passkeys technology. Passkeys enable users to securely log in using local user verification (such as biometrics or device PINs), often with credential synchronization across devices.

FIDO2：FIDO2 将 WebAuthn 与客户端到身份验证器协议 (CTAP) 结合起来。 U2F现命名为CTAP1； UAF 是一个单独的协议。 WebAuthn 凭证构成了现代密钥技术的基础。万能钥匙使用户能够使用本地用户验证（例如生物识别或设备 PIN）安全登录，通常会跨设备进行凭据同步。

Hardware-backed Key Storage / 硬件支持的密钥存储

For many authenticators, including common platform passkeys, the private key is generated and stored by the operating system's secure key manager. Depending on the platform and authenticator, keys may be protected using hardware-backed components such as the Trusted Platform Module (TPM) on Windows, Secure Enclave on Apple devices, or the Android Keystore/StrongBox on Android, or by other software-based mechanisms.

对于许多身份验证器，包括常见的平台密钥，私钥由操作系统的安全密钥管理器生成和存储。根据平台和身份验证器，密钥可能通过硬件支持组件（如Windows上的可信平台模块（TPM））、苹果设备上的安全 enclave 或 Android 上的Android Keystore/StrongBox 或其他基于软件的机制进行保护。

In typical implementations, the private key is intended to be non-exportable and bound to the authenticator, and the platform security module signs a server challenge using this key. However, some authenticators support credential synchronization or backup that may involve export or server-side storage, and not all implementations are hardware-backed. Relying parties should not assume that keys are hardware-backed and non-exportable unless this is verified (for example, via authenticator properties or attestation).

在典型的实现中，私钥是不可导出的并且绑定到验证器，并且平台安全模块使用该密钥对服务器质询进行签名。但是，某些身份验证器支持可能涉及导出或服务器端存储的凭证同步或备份，并且并非所有实现都是硬件支持的。依赖方不应假设密钥是由硬件支持且不可导出的，除非经过验证（例如，通过身份验证器属性或证明）。

Password Managers / 密码管理器

Password managers are programs, browser plugins, or web services that automate the management of a large quantity of different credentials. Most password managers have functionality to allow users to easily use them on websites, either: (a) by pasting the passwords into the login form -- or -- (b) by simulating the user typing them in.

密码管理器是程序、浏览器插件或网络服务，用于自动化管理大量不同的凭证。大多数密码管理器具有允许用户在网站上轻松使用的功能，无论是：(a) 通过将密码粘贴到登录表单中 -- 还是 -- (b) 通过模拟用户输入它们。

Web applications should not make the job of password managers more difficult than necessary by observing the following recommendations:

通过遵守以下建议，Web 应用程序不应使密码管理器的工作变得更加困难：

  • Use standard HTML forms for username and password input with appropriate type attributes.
    中文：使用标准的HTML表单进行用户名和密码输入，并使用适当的type属性。
  • Avoid plugin-based login pages (such as Flash or Silverlight).
    中文：避免使用基于插件的登录页面（如Flash或Silverlight）。
  • Implement a reasonable maximum password length, at least 64 characters, as discussed in the Implement Proper Password Strength Controls section.
    中文：实施合理的最大密码长度，至少 64 个字符，如实施适当的密码强度控制部分 中所述。
  • Allow any printable characters to be used in passwords.
    中文：允许在密码中使用任何可打印字符。
  • Allow users to paste into the username, password, and MFA fields.
    中文：允许用户粘贴到用户名、密码和 MFA 字段中。
  • Allow users to navigate between the username and password field with a single press of the Tab key.
    中文：允许用户通过按一下“Tab”键在用户名和密码字段之间导航。

Changing A User's Registered Email Address / 更改用户的注册电子邮件地址

User email addresses often change. The following process is recommended to handle such situations in a system:

用户电子邮件地址经常发生变化。建议采用以下流程来处理系统中的此类情况：

Note: The process is less stringent with Multifactor Authentication, as proof-of-identity is stronger than relying solely on a password.

注意：多重身份验证 的流程不太严格，因为身份证明比仅依赖密码更强。

  1. Confirm the validity of the user's authentication cookie/token. If not valid, display a login screen.
    中文：确认用户身份验证cookie/令牌的有效性。如果无效，显示登录界面。
  2. Describe the process for changing the registered email address to the user.
    中文：描述更改用户注册电子邮件地址的过程。
  3. Ask the user to submit a proposed new email address, ensuring it complies with system rules.
    中文：要求用户提交建议的新电子邮件地址，确保其符合系统规则。
  4. Request the use of Multifactor Authentication for identity verification.
    中文：请求使用多因素认证进行身份验证。
  5. Store the proposed new email address as a pending change.
    中文：将建议的新电子邮件地址存储为待更改。
  6. Create and store two time-limited nonces for (a) system administrators' notification, and (b) user confirmation.
    中文：为(a)系统管理员通知和(b)用户确认创建并存储两个时间限制性的随机数。

  7. Send two email messages with links that include those nonces:
    中文：发送包含这些随机数的链接的两个电子邮件消息。

    • A notification-only email message to the current address, alerting the user to the impending change and providing a link to report unexpected activity.
      中文：一封仅通知的电子邮件发送到当前地址，提醒用户即将发生的变更，并提供一个报告意外活动的链接。

    • A confirmation-required email message to the proposed new address, instructing the user to confirm the change and providing a link for unexpected situations.
      中文：需要确认的电子邮件发送到建议的新地址，指示用户确认更改并为意外情况提供链接。

  8. Handle responses from the links accordingly.
    中文：相应地处理来自链接的响应。

  1. Confirm the validity of the user's authentication cookie/token. If not valid, display a login screen.
    中文：确认用户身份验证cookie/令牌的有效性。如果无效，显示登录界面。
  2. Describe the process for changing the registered email address to the user.
    中文：描述更改用户注册电子邮件地址的过程。
  3. Ask the user to submit a proposed new email address, ensuring it complies with system rules.
    中文：要求用户提交建议的新电子邮件地址，确保其符合系统规则。
  4. Request the user's current password for identity verification.
    中文：请求用户的当前密码以进行身份验证。
  5. Store the proposed new email address as a pending change.
    中文：将建议的新电子邮件地址存储为待更改。
  6. Create and store three time-limited nonces for system administrators' notification, user confirmation, and an additional step for password reliance.
    中文：创建并存储三个有时间限制的随机数，用于系统管理员通知、用户确认以及密码可靠性的附加步骤。

  7. Send two email messages with links to those nonces:
    中文：发送两封包含这些随机数链接的电子邮件：

    • A confirmation-required email message to the current address, instructing the user to confirm the change and providing a link for an unexpected situation.
      中文：一封需要确认的电子邮件发送到当前地址，指示用户确认变更，并提供一个应对意外情况的链接。

    • A separate confirmation-required email message to the proposed new address, instructing the user to confirm the change and providing a link for unexpected situations.
      中文：需要单独确认的电子邮件发送到建议的新地址，指示用户确认更改并为意外情况提供链接。

  8. Handle responses from the links accordingly.
    中文：相应地处理来自链接的响应。

Notes on the Above Processes / 关于上述流程的说明

Adaptive or Risk Based Authentication / 自适应或基于风险的身份验证

A feature of more advanced applications is the ability to require different authentication stages depending on various environmental and contextual attributes (including but not limited to, the sensitivity of the data for which access is being requested, time of day, user location, IP address, or device fingerprint).

更高级应用的一个特性是能够根据各种环境和上下文属性（包括但不限于，请求访问的数据的敏感性、一天中的时间、用户位置、IP地址或设备指纹）要求不同的身份验证阶段。

For example, an application may require MFA for the first login from a particular device but not for subsequent logins from that device. Alternatively, a single sign-on solution may authenticate the user and allow them to remain logged in for a day but require a reauthentication if they try to access their profile page.

例如，应用程序可能需要 MFA 才能从特定设备首次登录，但随后从该设备登录则不需要。或者，单点登录解决方案可以对用户进行身份验证，并允许他们保持登录状态一天，但如果他们尝试访问其个人资料页面，则需要重新进行身份验证。

Use device fingerprints, IP addresses, and remembered-device cookies as risk signals, not as substitutes for authentication. NIST session guidance distinguishes an authenticated session secret from device and browser characteristics used for monitoring. Require authentication or a valid authenticated session before exposing private account data. For example, a banking application may allow balance viewing within an authenticated session and require stronger or fresher authentication for transaction details or money movement.

使用设备指纹、IP 地址和记住的设备 cookie 作为风险信号，而不是替代身份验证。 NIST 会话指南 将经过身份验证的会话密钥与用于监控的设备和浏览器特征区分开来。在公开私人帐户数据之前需要进行身份验证或有效的经过身份验证的会话。例如，银行应用程序可能允许在经过身份验证的会话中查看余额，并需要对交易详细信息或资金流动进行更强或更新的身份验证。

Questions that should be considered when implementing a mechanism like this include:

实施此类机制时应考虑的问题包括：

  • Are the policies being put in place in line with any corporate policies and especially any regulatory policy?
    中文：制定的政策是否符合公司政策，特别是监管政策？
  • Which user‑ or device‑attributes (IP, geolocation, device fingerprint, time‑of‑day, behavioral biometrics, etc.) will we monitor at session start?
    中文：我们将在会话开始时监控哪些用户或设备属性（IP、地理位置、设备指纹、时间、行为生物识别等）？
  • Which of those signals need to be refreshed during an active session, and at what cadence?
    中文：在活动会话期间，哪些信号需要刷新，刷新频率如何？
  • How will we ensure each signal’s accuracy and handle missing or low‑confidence data?
    中文：我们将如何确保每个信号的准确性，并处理缺失或低置信度数据？
  • What scoring model (weights, thresholds, ML, rule‑based, hybrid) will convert raw signals into a risk tier?
    中文：哪种评分模型（权重、阈值、机器学习、基于规则的、混合型）将把原始信号转换为风险等级？
  • Where will the model run (edge, API gateway, central service), and what is our latency budget?
    中文：模型将在哪里运行（边缘、API网关、中心服务），我们的延迟预算是多少？
  • What action maps to each risk tier (allow, CAPTCHA, step‑up MFA, block, revoke session)?
    中文：每个风险层对应哪些操作（允许、CAPTCHA、升级 MFA、阻止、撤销会话）？
  • What user‑facing messages and error codes will accompany each action?
    中文：每个操作将伴随哪些面向用户的消息和错误代码？
  • At which exact code or platform layers will we invoke the risk engine (login controller, middleware, API gateway, service mesh)?
    中文：我们将在哪一层精确的代码或平台层调用风险引擎（登录控制器、中间件、API网关、服务网格）？
  • How do we propagate decisions consistently across web, mobile, and API clients?
    中文：我们如何在 Web、移动和 API 客户端上一致地传播决策？
  • How do we mutate, extend, or revoke tokens/cookies when a mid‑session risk check escalates?
    中文：当会话风险检查升级时，我们如何变异、扩展或撤销令牌/cookie？
  • How do we synchronize state across multiple concurrent devices or browser tabs?
    中文：我们如何在多个并发设备或浏览器选项卡之间同步状态？
  • What monitoring and alerting will be in place for potentially suspicious activity, including how the user is notified.
    中文：针对潜在可疑活动将采取哪些监控和警报，包括如何通知用户。

References / 参考