5

I have a backend (API) and mobile apps.

Mobile apps user use same client_id (Oauth2).

Now I see many Bots signing up, adding credit card for checking them (carding)

I cannot throttle, limit them since the IP is always different also client_id for all mobile clients is the same.

What solutions would you propose to stop it?

If there is a way to identify each Mobile client uniquely I can throttle each for 1 request per second or something (to stop those automated Signup + Credit Card addition).

In the past fraudster created many accounts, but it could be also using one account (so I can also limit requests on it)

What are other solutions to this?

1 Answer 1

0

Some suggestions:

  • Redesign your OAuth architecture. You are using the same client_id for all clients, effectively enabling anonymous access to your resources. This is almost certainly wrong. In OAuth, the Authorization Server issues a Client Identifier to the client during the authorization flow. However, I don't think that this is the cause of your problems, since the entry point into your signup flow cannot be protected by OAuth. A typical approach to protect such a singup endpoint would be fairly restrictive IP-based rate limits, but you claim that each signup request uses a different IP so this is not feasible.

  • Improve identity verification during the signup flow, before credit cards can be added. This is going to depend a lot on the nature of your services (e.g. if credit cards are needed for age verification), but the general idea is to increase the attacker's cost for creating/discarding accounts. For example, sending a verification email introduces a small time cost, but throwaway email addresses are easy to create. Sending a verification SMS to a phone number can be a stronger protection in countries where SIM cards can only be acquired with ID, but is comparatively expensive. To some degree account verification can be outsourced, for example by using features like Google Sign-In / Sign in with Apple ID (which would re-introduce OAuth!). If someone registers a new account with username+password, that might indicate a higher-risk.

  • Lean into your platform's capabilities. Since you are writing mobile apps and not web apps, you have a rich and fairly secure platform to support you, such as the Google Play Integrity API. If the user's device is not rooted, you can perform some rate-limiting within the app. However, modern mobile OSes avoid providing stable identifiers due to privacy reasons. You may be able to collect additional device information to create a more accurate risk profile, but again there are privacy/legal/platform implications.

  • Outsource more aspects of credit card processing. Depending on your context, it can be worth implementing in-app payments rather than handling credit card info via your backend (also simplifies your compliance). While that is expensive, it can sometimes be less expensive than dealing with fraud yourself. Depending on where and how you publish your app, you may be required to use Google/Apple payment infrastructure anyways.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .