Update: Credential Stuffing Prevention Cheat Sheet

[sandyblizzard]

What is missing or needs to be updated?

The Credential Stuffing Prevention Cheat Sheet would benefit from numerous additions that reflect the current state of credential stuffing attacks.

How should this be resolved?

• The cheat sheet should incorporate information regarding account validation attacks. This is a related attack that may proceed credential stuffing, where a bad actor identifies what accounts exist on a platform. Invalid accounts are pruned from their credential list, thereby increasing the efficiency of a subsequent credential stuffing attack. This type of attack will typically abuse a customer sign-up process that rejects the creation of new accounts when usernames or email address are already in use.

• The IP Block list section could use numerous updates, especially when considering credential stuffing against customer facing authentication endpoints.

  • Commonly used credential stuffing toolkits can leverage proxy networks which can greatly expand the possible IPv4 addresses seen.
  • While known malicious IPv4 addresses are leveraged for automated fraud, their use increases the risk that credential stuffing and other fraud will be detected. Defenders should also collect IPv4 proxy intelligence and incorporate it into authentication defenses.
  • In addition to proxy intelligence, defenders should collect and utilize lists of IP address ranges for major hosting providers. This data can not only be incorporated into anti-automation controls, but can be used as a truth test for other data points. As an example: user agent strings. If an IP that belongs to an AWS EC2 range transmits a request with 'iPhone' in it's user agent string, it is highly likely that it is fake or an automated process of some sort.
  • While tracking activity by IPv4 address is useful, the IP address range that the address belongs to should be considered as well. A bad actor leveraging a hosting provider may be able to acquire a new IP quickly once they detect that their current IPv4 address is being mitigated, and start their activities fresh. As an example, if an automated blocklist system mitigates abusive IPv4 addresses every 10 minutes, but a hosting provider takes a minute to provision a new IPv4 address for a server, a bad actor has approximately 9 minutes where their new IPv4 address is not mitigated. They could automate their credential stuffing toolkit to making this rotation automatically.
  • Given that credential stuffing attacks may leverage residential proxy networks, defenders should be mindful of blocking IPv4 addresses based solely on volume.
  • In addition to blocklists, rate limiting based on the type of IP address range is an option that allows for a more tailored mitigation. For example, a UK based e-commerce merchant might generally allow 100 requests per minute from any IPv4 address, but only 5 per minute from US hosting providers.

• Require unpredictable usernames section should be reformatted into three sections.

  • The Request unpredictable usernames remains, but shortened. Unique usernames helps prevent credentials from one platform being successfully used on other platforms, but may not protect against credentials sourced from data breaches or malware infection when the email address is part of the breach.
  • A new 'password reuse' section should incorporate some of the content from 'request unpredictable usernames', and expand on it. Password re-use is one of the primary enablers of cross-platform credential stuffing attacks. Password re-use across platforms can be prevented by user education, password policies/requirements and the identification of leaked passwords.
  • The 3rd section would be on password policies. Specifically, passwords should be rotated periodically, historical passwords should not be allowed and the top 100k passwords should be disallowed. The current year should also not be allowed as a portion of the password; otherwise users may use the same base password in combination with the current year.

• The defense in depth section should have several items added to it:

  • A 'device challenge' section should be added. A device challenge delivers a computational task that must be completed to the device making an authentication request. An example might be a computationally intensive math challenge.
  • On the more extreme end of defensive measures, a section on 'Connection Degredation' should be added. Instead of blocking, if technology permits, credential stuffing requests are arbitrarily slowed down. This might be accomplished by introducing long wait periods into application code, replacement of HTML images with overly large versions (512kb replaced with 10mb) or randomized error messages (i.e. return server error messages instead of an auth failure message).
  • A section should be added on identifying automation via connection fingerprinting. Namely, browser header order (see https://aws.amazon.com/about-aws/whats-new/2023/01/amazon-cloudfront-request-header-order-count-headers/) and SSL/TLS fingerprinting (https://github.com/salesforce/ja3).

• A section on operational security considerations should be added. Namely, the idea that an authentication endpoint should not give an indication that the password succeed or failed when additional checks, such as MFA are performed. As an example, if a user must enter the correct password to see the MFA screen, a bad actor could leverage this as an indicator that the password was correct. Further, security staff may see a large volume of authentication attempts with 0% success rate due to MFA failures, and incorrectly conclude defenses worked as intended.

• A more extreme rewrite of the cheat sheet could be organized in the following fashion:

  • Introduction to the topic
  • Mitigations organized by what technology stack they are most closely associated with:
  • End user/client defenses, such as device fingerprinting, computational payloads, cookies, etc.
  • Network (CDN, Firewalls, etc) defenses such as connection fingerprinting (JA3, header order), IPv4 blocklists, rate limiting, etc
  • Application controls such as MFA or password policies or real time anti-fraud/abuse checks.
  • Post-activity or retroactive controls that identify customers with leaked passwords, customers who authenticated from an IPv4 address identified as abusive, fraud/risk systems, etc.

[szh]

Hi @sandyblizzard,

Sorry for the delay in responding to this. I think this is fantastic and would love for you to work on it.

The only comment I have is around password strength controls:

The 3rd section would be on password policies. Specifically, passwords should be rotated periodically, historical passwords should not be allowed and the top 100k passwords should be disallowed. The current year should also not be allowed as a portion of the password; otherwise users may use the same base password in combination with the current year.

I would recommend trying to keep this guidance consistent with the guidelines in the Authentication Cheat Sheet and the links provided there, particularly ASVS (updated link). It's likely that the Authentication Cheat Sheet will itself need an update and this may be an opportune time to handle that as well, once you're working on this topic.

[sandyblizzard]

Thanks! Good point on the password strength; I am reviewing the authentication cheat sheet. I've already noticed that the ACS uses the term 'user enumeration' while I am using 'account validation'. I plan on adopting the existing term instead.

[sandyblizzard]

As an update, I will be putting in a pull request with proposed changes early next on Nov 6th or 7th.