Mitigate Card Testing Attacks - Best Practices
- Anna Frazier
- Miles Graves
In collaboration with Worldpay from FIS, Payrix has seen an increase in the number of card testing attacks globally and we advise you and any of your service providers to be diligent, increase your awareness and review your current detection controls to help prevent these types of fraudulent attacks.
We will continue to notify you of any suspicious authorization activity that may be potential card testing, but additionally, we worked in partnership with the Card Brands to produce a list below of best practices to assist with any mitigation efforts:
Actions
Leverage authentication and CAPTCHA controls to prevent automated transaction initiation by bots or scripts (e.g., 5 authorizations from one IP address or Account)
Utilize fraud detection systems that support device fingerprinting and botnet detection
Use a layered validation approach that employs Card Validation Codes and Address Verification Services
Analyze time zone differences and browser language consistency from the cardholder’s IP address and device. Classify these transactions as potentially high risk and perform more stringent reviews
Inject random pauses (i.e., throttling) when checking an account to slow brute force attacks that are dependent on time, especially for Bank Identification Numbers (BINs) that have been determined to have a high fraud incidence
Include IP address with multiple failed card payment data in a fraud detection blacklist database for review and analysis
In addition to velocity checks for small and large transactions, use velocity checks for low amounts or authorization-only transactions
Awareness
Look for excessive usage and bandwidth consumption from a single user
Look for multiple tracking elements in a purchase linked to the same device (e.g., multiple transactions with different cards, using the same e-mail address and same device ID)
Look for logins on a single account coming from many IP addresses
Review logins with suspicious passwords that hackers commonly use
Lock out an account if a user guesses the username/password and any account authentication data incorrectly on “x” number of login attempts
PayFields Best Practices
The Payrix PayFields and PayFrame products are typically used as a hosted checkout field on public payment pages, such as shopping card checkout, company payment pages, donation pages, and other publicly viewable payment pages. As these payment pages can be viewed and utilized in a public space, they can be vulnerable to to be used for card testing purposes.
It is recommend to follow a few best practices when utilizing PayFields in a public form to ensure the security of the information and to deter anyone from using PayFields for card testing:
Ensure that the API key that is used with the PayFields is a public API key:
We have two types of API keys, a public and a private key. The public key is limited to certain POST calls, while a private key can be used for GET calls, and can be used to gain more access to an account. If a payment page is public a Private API key should never be used in that page.
Created a dedicated user to host the API key:
The API key will inherit the level of access from the user that it is associated with. Creating a specific user that is designated as the user for the API key, will allow you to limit the access that the API key is granted.
Only utilize PayFields to create tokens:
This may seem counterintuitive, since PayFields has the abilty to create transactions right there, but this can add a great layer of security. Below I will outline the steps that you can take to integrate in this manner.
This will allow you to create velocity controls within your own environment. If you notice traffic coming from a specific source that is higher than expected, you can block it before it even comes through to Payrix
Add additional Transaction decisions
We recommend adding a failed authorization rule on all merchants. In the event that someone does start to use the page for card testing, this will mitigate the exposure, as they will continue to get blocked when the number of declines exceeds the rule in place, which will ultimately guide them to go elsewhere.
Create a rolling API key, so that there isn’t one API key in use for more than a specific timeframe
In the event that an API key is compromised, the shorter the amount of time it remains active will help to mitigate any potential undesired outcomes. What you can do to avoid this, is to create a rolling API key, so that a new API key is utilized every 6 hours. Below are the steps that you can use to completed this.