REST API from a mobile application. Is the first call secure with CAPTCHA?

Question

Let's say I have an iOS / Android application that relies on a custom REST API for things like account management (registration, login, password reset, getting / setting user-related data).

There is no good way to ensure that my API is only called from my mobile application. Oauth2 and the like with "secret" in the client code - can be easily reconstructed.

Say I have an API call:

https://www.myapi.com/register_user?username=UUU&password=PPP&email=EEE

(of course, not quite like that, but you get the point)

This will create a new user, and then all API calls will either include a session token, or something that links the API call to a specific application user with the account.

This first registration call is the only one that is not protected by anything, and it worries me that a malicious person calls him 1,000,000 times with a PC script to create many fake users, especially with real email addresses. People with these addresses will not be able to use the application.

So, how do you protect this very first API call to prevent massive abuse? I am going to include in the user registration form approved by the CAPTCHA server for mobile devices.

Again, all subsequent API calls are protected by the session token and the number of API call calls for each user (suspicious ones are blocked).

It makes sense? Am I complicating things too much? Thank you very much

PS: Other interesting alternatives seem to include using authentication or a reliable third-party identity provider such as Google, etc. - None of these 3 options is perfect. In any case, they are interested in discussing this problem.

Answer 1

I suggest that CAPTCHA be the second level of protection that will be enabled when you see a registration violation. There are several different angles here:

1. Do you need this protection at all?

If you do not assign expensive resources immediately after requesting an account, all that happens is the creation of a group of database records. If you are allocating resources immediately, you need to change the onboarding flow so that users receive them only after they have legitimately checked their emails and entered the application. You can separately set up the cleaning work so that all queries that were not activated within a reasonable period (maybe two weeks?) Are deleted from the database.

2. Do you have real-time monitoring of registration?

If you can stay on top of registration API calls, you can prevent most abuse attempts. In most cases, you are trying to improve the number of new users who subscribe. When monitoring / warning you can take protective actions when the registration behavior begins to look suspicious. For instance:

• A sudden major surge in API calls without any trigger from your end (such as new marketing campaigns or a blog post).
• Too many registration attempts from the same IP or IP range
• Observing the same values ​​in the header of the HTTP request (provided that when the API is called, your application makes passes through some values ​​for the client and does not use the header of the static request)

3. Abuse Prevention Options

As I said at the beginning, CAPTCHA can be the second level, where the first level must have a throttling function for registration requests. With each new attempt to register from the same IP address, you can exponentially take longer to respond. After too many attempts are observed, and the response time is already quite long, you can start to request a CAPTCHA.

Hopefully at this point you will abuse under control. But also be prepared to start blocking / temporarily barring API calls if CAPTCHA does not produce the expected result.

By the way, this and most other anti-abuse features will benefit from the ability to configure your service on the fly, play with different values ​​/ parameters when observing and analyzing effects.