Credential Stuffing Prevention Cheat Sheet / 凭证填充预防技巧清单

Introduction / 介绍

This cheatsheet covers defenses against two common types of authentication-related attacks: credential stuffing and password spraying. Although these are separate, distinct attacks, in many cases the defenses that would be implemented to protect against them are the same, and they would also be effective at protecting against brute-force attacks. A summary of these different attacks is listed below:

这份技巧清单涵盖了针对两种常见的与身份验证相关的攻击的防御措施：凭证填充和密码喷洒。尽管这两种攻击是分开的、不同的，但在许多情况下，为防止这些攻击而实施的防御措施是相同的，并且它们也适用于防止暴力破解攻击。以下列出了这些不同攻击的摘要：

Attack Type / 攻击类型	Description / 描述
Brute Force 暴力破解	Testing multiple passwords from 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. 对大量不同账户测试单个弱密码。

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

Multi-factor authentication (MFA) （多因素身份验证（MFA）） is by far the best defense against the majority of password-related attacks, including credential stuffing and password spraying, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises. As such, it should be implemented wherever possible. Historically, depending on the audience of the application, it may not have been practical or feasible to enforce the use of MFA, however with modern browsers and mobile devices now supporting FIDO2 Passkeys and other forms of MFA, it is attainable for most use cases.

In order to balance security and usability, multi-factor authentication can be combined with other techniques to require the 2nd factor only in specific circumstances where there is reason to suspect that the login attempt may not be legitimate, such as a login from:

为了平衡安全性和可用性，多因素身份验证可以与其他技术结合使用，仅在怀疑登录尝试可能不合法的情况下才要求第二因素，例如来自：

• A new browser/device or IP address.
  中文：新的浏览器/设备或IP地址。
• An unusual country or location.
  中文：不寻常的国家或地区。
• Specific countries that are considered untrusted or typically do not contain users of a service.
  中文：被认为不可信或通常不包含服务用户的特定国家。
• An IP address that appears on known denylists or is associated with anonymization services, such as proxy or VPN services.
  中文：出现在已知拒绝列表上或与匿名化服务（如代理或VPN服务）相关的IP地址。
• An IP address that has tried to login to multiple accounts.
  中文：尝试登录多个账户的IP地址。
• A login attempt that appears to be scripted or from a bot rather than a human (i.e. large login volume sourced from a single IP or subnet).
  中文：看起来像是脚本或机器人而非人类进行的登录尝试（即来自单个IP或子网的大规模登录）。

Or an organization may choose to require MFA in the form of a "step-up" authentication for the above scenarios during a session combined with a request for a high risk activity such as:

或者，组织可以选择在会话期间，对于上述场景要求进行“提升”认证的多因素认证，并结合请求高风险活动，例如：

• Large currency transactions
  中文：大额货币交易
• Privileged or Administrative configuration changes
  中文：特权或管理配置更改

Additionally, for enterprise applications, known trusted IP ranges could be added to an allowlist so that MFA is not required when users connect from these ranges.

此外，对于企业应用程序，可以将已知的可信IP范围添加到允许列表中，以便用户从这些范围连接时不需要多因素认证。

Alternative Defenses / 替代防御措施

Where it is not possible to implement MFA, there are many alternative defenses that can be used to protect against credential stuffing and password spraying. In isolation none of these are as effective as MFA, however multiple, layered defenses can provide a reasonable degree of protection. In many cases, these mechanisms will also protect against brute-force or password spraying attacks.

在不支持实施多因素认证的情况下，可以采用许多替代防御措施来保护免受凭证填充和密码喷洒攻击。然而，单独使用这些防御措施并不如多因素认证有效，但多层防御可以提供合理的保护程度。在许多情况下，这些机制还可以防止暴力破解或密码喷洒攻击。

Where an application has multiple user roles, it may be appropriate to implement different defenses for different roles. For example, it may not be feasible to enforce MFA for all users, but it should be possible to require that all administrators use it.

如果一个应用程序具有多个用户角色，为不同的角色实施不同的防御措施可能是合适的。例如，可能无法强制所有用户实施多因素认证，但应要求所有管理员使用它。

Defense in Depth & Metrics / 深度防御与指标

While not a specific technique, it is important to implement defenses that consider the impact of individual defenses being defeated or otherwise failing. As an example, client-side defenses, such as device fingerprinting or JavaScript challenges, may be spoofed or bypassed and other layers of defense should be implemented to account for this.

虽然这不是一种具体的技术，但实施考虑个别防御被击败或失败的防御措施很重要。例如，客户端防御，如设备指纹识别或JavaScript挑战，可能会被欺骗或绕过，因此应实施其他防御层来应对这种情况。

Additionally, each defense should generate volume metrics for use as a detective mechanism. Ideally the metrics will include both detected and mitigated attack volume and allow for filtering on fields such as IP address. Monitoring and reporting on these metrics may identify defense failures or the presence of unidentified attacks, as well as the impact of new or improved defenses.

此外，每个防御措施都应生成用于检测机制的流量指标。理想情况下，这些指标应包括检测和缓解的攻击量，并允许根据IP地址等字段进行过滤。监控和报告这些指标可能有助于识别防御失败或未识别的攻击的存在，以及新或改进的防御措施的影响。

Finally, when administration of different defenses is performed by multiple teams, care should be taken to ensure there is communication and coordination when separate teams are performing maintenance, deployment or otherwise modifying individual defenses.

最后，当不同防御措施的管理由多个团队执行时，应确保在单独的团队进行维护、部署或修改个别防御措施时进行沟通和协调。

Secondary Passwords, PINs and Security Questions / 二级密码、PIN码和安全问题

Do not use security questions as an additional authentication challenge. OWASP ASVS 5.0 requirement 6.4.2 excludes knowledge-based security questions. The Security Questions Cheat Sheet discusses limitations in legacy systems.

不要将安全问题用作额外的身份验证挑战。OWASP ASVS 5.0要求6.4.2排除了基于知识的安全问题。安全问题作弊表讨论了在旧系统中的局限性。

If a secondary password, PIN, or memorable word is used, request and verify the entire secret rather than selected characters, as required by NIST SP 800-63B-4. Adding another knowledge factor does not constitute MFA; prefer an independent factor instead.

如果使用二级密码、PIN码或记忆词，应按照NIST SP 800-63B-4的要求，请求并验证整个密钥，而不是所选字符。添加另一个知识因素并不构成MFA；建议使用独立的因素。

CAPTCHA

Requiring a user to solve a "Completely Automated Public Turing test to tell Computers and Humans Apart" (CAPTCHA) or similar puzzle for each login attempt can help to identify automated/bot attacks and help prevent automated login attempts, and may slow down credential stuffing or password spraying attacks. However, CAPTCHAs are not perfect, and in many cases tools or services exist that can be used to break them with a reasonably high success rate. Monitoring CAPTCHA solve rates may help identify impact to good users, as well as automated CAPTCHA breaking technology, possibly indicated by abnormally high solve rates.

要求用户在每次登录尝试时解决“完全自动化的图灵测试以区分计算机和人类”(CAPTCHA)或类似的谜题，可以帮助识别自动化/机器人攻击，并有助于防止自动化登录尝试，可能减缓凭证填充或密码喷射攻击。然而，CAPTCHA并不完美，在许多情况下，存在可以以相当高的成功率破解它们的工具或服务。监控CAPTCHA解决率可能有助于识别对良好用户的影响，以及自动化破解CAPTCHA的技术，这可能表现为异常高的解决率。

To improve usability, it may be desirable to only require the user solve a CAPTCHA when the login request is considered suspicious or high risk, using the same criteria discussed in the MFA section.

为了提高可用性，可能只要求用户在登录请求被认为可疑或高风险时解决CAPTCHA，使用与MFA部分中讨论的相同标准。

IP Mitigation and Intelligence / IP缓解和情报

Blocking IP addresses may be sufficient to stop less sophisticated attacks, but should not be used as the sole or primary defense due to the ease in circumvention. It is more effective to have a graduated response to abuse that leverages multiple defensive measures depending on different factors of the attack.

阻止IP地址可能足以阻止不太复杂的攻击，但不应将其作为唯一或主要防御手段，因为绕过它们很容易。更有效的方法是采取逐步响应滥用行为，根据攻击的不同因素采取多种防御措施。

Any process or decision to mitigate (including blocking and CAPTCHA) credential stuffing traffic from an IP address should consider a multitude of abuse scenarios, and not rely on a single predictable volume limit. Short (i.e. burst) and long time periods should be considered, as well as high request volume and instances where one IP address, likely in concert with many other IP addresses, generates low but consistent volumes of traffic. Additionally, mitigation decisions should consider factors such as IP address classification (ex: residential vs hosting) and geolocation. These factors may be leveraged to raise or lower mitigation thresholds in order to reduce potential impact on legitimate users or more aggressively mitigate abuse originating from abnormal sources. Mitigations, especially blocking an IP address, should be temporary and processes should be in place to remove an IP address from a mitigated state as abuse declines or stops.

任何缓解（包括阻止和CAPTCHA）凭证填充流量从IP地址的过程或决策都应考虑多种滥用场景，而不仅仅依赖于单一可预测的流量限制。应考虑短期（即突发）和长期时间段，以及高请求量和单个IP地址（可能与其他许多IP地址协同）生成低但稳定的流量实例。此外，缓解决策应考虑因素，如IP地址分类（例如：住宅与托管）和地理位置。这些因素可以用来提高或降低缓解阈值，以减少对合法用户的影响或更积极地缓解来自异常来源的滥用。缓解措施，尤其是阻止IP地址，应该是临时的，并且应建立流程，在滥用减少或停止时将IP地址从缓解状态中移除。

Many credential stuffing toolkits, such as Sentry MBA, offer built-in use of proxy networks to distribute requests across a large volume of unique IP addresses. This may defeat both IP block-lists and rate limiting, as per IP request volume may remain relatively low, even on high volume attacks. Correlating authentication traffic with proxy and similar IP address intelligence, as well as hosting provider IP address ranges can help identify highly distributed credential stuffing attacks, as well as serve as a mitigation trigger. For example, every request originating from a hosting provider could be required to solve CAPTCHA.

许多凭证填充工具包，如Sentry MBA，提供内置的代理网络使用，以在大量唯一的IP地址之间分配请求。这可能会同时击败IP阻止列表和速率限制，因为根据IP请求量可能相对较低，即使在高流量攻击中也是如此。将身份验证流量与代理和类似IP地址情报以及托管提供商IP地址范围相关联，可以帮助识别高度分布的凭证填充攻击，并作为缓解触发器。例如，每个来自托管提供商的请求都可能需要解决CAPTCHA。

There are both public and commercial sources of IP address intelligence and classification that may be leveraged as data sources for this purpose. Additionally, some hosting providers publish their own IP address space, such as AWS.

存在公共和商业来源的IP地址情报和分类，这些可以作为数据源。此外，一些托管提供商会发布他们自己的IP地址空间，例如AWS。

Separate from blocking network connections, consider storing an account's IP address authentication history. In case a recent IP address is added to a block or mitigation list, it may be appropriate to lock the account and notify the user.

除了阻止网络连接之外，考虑存储账户的IP地址认证历史。如果最近添加的IP地址被列入阻止或缓解列表，锁定账户并通知用户可能是适当的。

Device Fingerprinting / 设备指纹识别

Aside from the IP address, there are a number of different factors that can be used to attempt to fingerprint a device. Some of these can be obtained passively by the server from the HTTP headers (particularly the "User-Agent" header), including:

除了IP地址之外，还有许多不同的因素可以用来尝试识别设备。其中一些可以通过服务器从HTTP头（尤其是“User-Agent”头）被动获取，包括：

• Operating system & version
  中文：操作系统及版本
• Browser & version
  中文：浏览器及版本
• Language
  中文：语言

Using JavaScript it is possible to access far more information, such as:

使用JavaScript可以访问更多信息，例如：

• Screen resolution
  中文：屏幕分辨率
• Installed fonts
  中文：已安装字体
• Installed browser plugins
  中文：已安装浏览器插件

Using these various attributes, it is possible to create a fingerprint of the device. This fingerprint can then be matched against any browser attempting to login to the account, and if it doesn't match then the user can be prompted for additional authentication. Many users will have multiple devices or browsers that they use, so it is not practical to simply block attempts that do not match the existing fingerprints, however it is common to define a process for users or customers to view their device history and manage their remembered devices. Also these attributes can be used to detect anomalous activity such as a device appearing to be running an older version of OS or Browser.

通过使用这些各种属性，可以创建设备的指纹。然后可以将这个指纹与任何尝试登录账户的浏览器进行匹配，如果不匹配，则可以提示用户进行额外的身份验证。许多用户会使用多个设备或浏览器，因此简单地阻止与现有指纹不匹配的尝试并不实际，但通常为用户或客户定义一个查看设备历史记录和管理已记住的设备的过程。此外，这些属性还可以用于检测异常活动，例如设备似乎正在运行较旧的操作系统或浏览器版本。

The fingerprintjs2 JavaScript library can be used to carry out client-side fingerprinting.

可以使用 fingerprintjs2 JavaScript 库进行客户端指纹识别。

It should be noted that as all this information is provided by the client, it can potentially be spoofed by an attacker. In some cases spoofing these attributes is trivial (such as the "User-Agent") header, but in other cases it may be more difficult to modify these attributes.

需要注意的是，由于所有这些信息都是由客户端提供的，因此可能被攻击者伪造。在某些情况下，伪造这些属性是微不足道的（例如 "User-Agent" 头部），但在其他情况下，可能更难修改这些属性。

Connection Fingerprinting / 连接指纹识别

Similar to device fingerprinting, there are numerous fingerprinting techniques available for network connections. Some examples include JA3, HTTP/2 fingerprinting and HTTP header order. As these techniques typically focus on how a connection is made, connection fingerprinting may provide more accurate results than other defenses that rely on an indicator, such as an IP address, or request data, such as user agent string.

与设备指纹识别类似，针对网络连接有众多指纹识别技术可用。一些例子包括 JA3、HTTP/2 指纹识别和 HTTP 头部顺序。由于这些技术通常关注连接的建立方式，因此连接指纹识别可能比依赖于指标（如 IP 地址）或请求数据（如用户代理字符串）的其他防御措施提供更准确的结果。

Connection fingerprinting may also be used in conjunction with other defenses to ascertain the truthfulness of an authentication request. For example, if the user agent header and device fingerprint indicates a mobile device, but the connection fingerprint indicates a Python script, the request is likely suspect.

连接指纹技术也可以与其他防御措施结合使用，以确认身份验证请求的真实性。例如，如果用户代理头和设备指纹表明是移动设备，但连接指纹表明是Python脚本，则请求可能存在问题。

Require Unpredictable Usernames / 要求不可预测的用户名

Credential stuffing attacks rely on not just the re-use of passwords between multiple sites, but also the re-use of usernames. A significant number of websites use the email address as the username, and as most users will have a single email address they use for all their accounts, this makes the combination of an email address and password very effective for credential stuffing attacks.

凭证填充攻击不仅依赖于在多个网站之间重复使用密码，还依赖于重复使用用户名。许多网站使用电子邮件地址作为用户名，由于大多数用户将使用单个电子邮件地址来管理所有账户，因此将电子邮件地址和密码组合起来对凭证填充攻击非常有效。

Requiring users to create their own username when registering on the website makes it harder for an attacker to obtain valid username and password pairs for credential stuffing, as many of the available credential lists only include email addresses. Providing the user with a generated username can provide a higher degree of protection (as users are likely to choose the same username on most websites), but is user unfriendly. Additionally, care needs to be taken to ensure that the generated username is not predictable (such as being based on the user's full name, or sequential numeric IDs), as this could make enumerating valid usernames for a password spraying attack easier.

要求用户在网站上注册时创建自己的用户名，使得攻击者更难获取有效的用户名和密码对，因为许多可用的凭证列表仅包括电子邮件地址。为用户提供生成的用户名可以提供更高的保护程度（因为用户很可能在大多数网站上选择相同的用户名），但这可能不太友好。此外，还需要注意确保生成的用户名不可预测（例如基于用户的完整姓名或顺序数字ID），因为这可能会使密码喷射攻击中枚举有效用户名变得更容易。

Multi-Step Login Processes / 多步骤登录过程

The majority of off-the-shelf tools are designed for a single step login process, where the credentials are POSTed to the server, and the response indicates whether or not the login attempt was successful. By adding additional steps to this process, such as requiring the username and password to be entered sequentially, or requiring that the user first obtains a random CSRF Token before they can login, this makes the attack slightly more difficult to perform, and doubles the number of requests that the attacker must make.

大多数现成的工具都是为单步登录过程设计的，其中凭证通过POST发送到服务器，响应指示登录尝试是否成功。通过在此过程中添加额外的步骤，例如要求按顺序输入用户名和密码，或者要求用户在登录之前首先获取一个随机的CSRF令牌，这使得攻击稍微困难一些，并且攻击者必须发出的请求数量翻倍。

Multi-step login processes, however, should be mindful that they do not facilitate user enumeration. Enumerating users prior to a credential stuffing attack may result in a harder to identify, lower request volume attack.

然而，多步骤登录过程应谨慎，不要促进用户枚举。在凭证填充攻击之前枚举用户可能会导致难以识别、请求量较低的攻击。

Require JavaScript and Block Headless Browsers / 要求JavaScript并阻止无头浏览器

Most tools used for these types of attacks will make direct POST requests to the server and read the responses, but will not download or execute JavaScript that was contained in them. By requiring the attacker to evaluate JavaScript in the response (for example to generate a valid token that must be submitted with the request), this forces the attacker to either use a real browser with an automation framework like Selenium or Headless Chrome, or to implement JavaScript parsing with another tool such as PhantomJS. Additionally, there are a number of techniques that can be used to identify Headless Chrome or PhantomJS.

大多数用于此类攻击的工具将直接向服务器发送POST请求并读取响应，但不会下载或执行其中包含的JavaScript。通过要求攻击者评估响应中的JavaScript（例如生成必须与请求一起提交的有效令牌），这迫使攻击者要么使用带有自动化框架如Selenium或无头Chrome的真实浏览器，要么使用PhantomJS等工具实现JavaScript解析。此外，还有多种技术可以用来识别无头Chrome或PhantomJS。

Please note that blocking visitors who have JavaScript disabled will reduce the accessibility of the website, especially to visitors who use screen readers. In certain jurisdictions this may be in breach of equalities legislation.

请注意，阻止禁用JavaScript的访问者将降低网站的可用性，特别是对使用屏幕阅读器的访问者。在某些司法管辖区，这可能违反平等立法。

Degradation / 降级

A more aggressive defense against credential stuffing is to implement measures that increase the amount of time the attack takes to complete. This may include incrementally increasing the complexity of the JavaScript that must be evaluated, requiring users to solve a cryptographic or Proof-of-Work computational puzzle, introducing long wait periods before responding to requests, returning overly large HTML assets or returning randomized error messages.

针对凭证填充的更积极防御措施是实施增加攻击完成所需时间的措施。这可能包括逐步增加必须评估的JavaScript的复杂性，要求用户解决密码学或工作量证明计算谜题，在响应请求之前引入长时间等待期，返回过大的HTML资源或返回随机错误消息。

These techniques provide some level of security without resorting to user tracking or profiling. They typically do not require a human in the loop, but rather constrain the minimum latency and/or the maximum request rate of a particular client implementation and the attacker's budget and sophistication, and requires a context-dependent risk assessment to gauge their efficacy, resistance to countermeasures and user experience impact.

这些技术提供了一定程度的安全性，而无需依赖用户跟踪或分析。它们通常不需要人工干预，而是限制特定客户端实现和攻击者的最小延迟和/或最大请求速率，以及攻击者的预算和复杂性，并需要基于特定情境的风险评估来评估其有效性、对反制措施的抵抗力以及用户体验影响。

Identifying Leaked Passwords / 识别泄露的密码

ASVS v4.0 Password Security Requirements) （ASVS v4.0 密码安全要求） provision (2.1.7) on verifying new passwords presence in breached password datasets should be implemented.

There are both commercial and free services that may be of use for validating passwords presence in prior breaches. A well known free service for this is Pwned Passwords. You can host a copy of the application yourself, or use the API.

有商业和免费服务可用于验证密码是否存在于以前的泄露中。此免费服务之一是Pwned Passwords。您可以自己托管应用程序的副本，或使用API。

Notify users about unusual security events / 通知用户关于不寻常的安全事件

When suspicious or unusual activity is detected, it may be appropriate to notify or warn the user. However, care should be taken that the user does not get overwhelmed with a large number of notifications that are not important to them, or they will just start to ignore or delete them. Additionally, due to frequent reuse of passwords across multiple sites, the possibility that the users email account has also been compromised should be considered.

当检测到可疑或异常活动时，通知或警告用户可能是适当的。然而，应小心不要让用户被大量对他们来说不重要的通知所淹没，否则他们可能会开始忽略或删除这些通知。此外，由于密码在多个网站上频繁重复使用，应考虑用户电子邮件账户也可能已被入侵的可能性。

For example, it would generally not be appropriate to notify a user that there had been an attempt to login to their account with an incorrect password. However, if there had been a login with the correct password, but which had then failed the subsequent MFA check, the user should be notified so that they can change their password. Subsequently, should the user request multiple password resets from different devices or IP addresses, it may be appropriate to prevent further access to the account pending further user verification processes.

例如，通常不适宜通知用户有人尝试使用错误的密码登录他们的账户。然而，如果有人使用正确的密码登录，但随后在多因素认证检查中失败，用户应被通知以便他们可以更改密码。随后，如果用户从不同的设备或IP地址请求多次密码重置，可能适宜阻止进一步访问账户，直到进行进一步的用户验证流程。

Details related to current or recent logins should also be made visible to the user. For example, when they login to the application, the date, time and location of their previous login attempt could be displayed to them. Additionally, if the application supports concurrent sessions, the user should be able to view a list of all active sessions, and to terminate any other sessions that are not legitimate.

应将有关当前或最近登录的详细信息提供给用户。例如，当他们登录应用程序时，可以显示他们上次登录尝试的日期、时间和位置。此外，如果应用程序支持并发会话，用户应能够查看所有活动会话的列表，并终止任何非合法的会话。

References / 参考

• OWASP: Credential Stuffing) （OWASP：凭证填充）
• NIST SP 800-63B-4: Password Verifiers) （NIST SP 800-63B-4：密码验证器）