REST API: does securing the first call with a CAPTCHA make sense?

Question

Let's say I have an iOS/Android app which rely on a custom REST API for things such as account management (register, login, password reset, get/set user-related data).

There is no good way to guarantee my API is only called from my mobile application. Oauth2 and the like with 'secret' in the client code can be easily reverse-engineered.

Let's say I have an API call like this:
https://myapi.example.com/register_user?username=UUU&password=PPP&email=EEE

This creates a new user and from then on all API calls will either include a session-token or something that ties the API call to a specific app user with an account.

This first registration call is the only one that is not protected by anything and what I'm worried about is that a malicious person calls it 1,000,000 times from a PC script to create lots of fake users, especially with real email addresses. Then people with these addresses won't be able to use the app.

How can I protect that very first API call to prevent mass misuse? I'm thinking of including a server-validated mobile-friendly CAPTCHA in the user registration form.

Again, all subsequent API calls are protected with session-token and API-call-count monitored per user (suspicious ones are blocked).

It's about designing the API in such a way that even if used from an inherently unsafe client like a mobile phone, it is still fine. Basically even if the API were to be made completely public, nobody could do much wrong with it. So here the question focuses on protecting that first API call but it's also about solving a more general problem.

It seems other interesting alternatives include using email-validation or a solid third-party identity provider like Google and the like. None of these 3 options is perfect. Anyway, interested in the discussion around this issue.

Does that make sense? Am I over-complicating things?

Answer 1

The standard approach to this would be to e-mail the user to confirm the account and if this doesn't occur in a pre-defined period of time, to delete the registration.

You could combine this with some Anomaly detection so for example if you got large numbers of registrations from a single IP address you could assume that this is hostile and block that IP address. Not perfect against a determined attacker but could deter less determined ones.

You could also add something like a CAPTCHA to the registration process, again this could deter less determined attackers but there are a number of ways round these, such as CAPTCHA completion services which are relatively inexpensive, so a determined attacker could bypass them.

Which of these are reasonable largely depends on the risk/threat profile of your application.

Answer 2

I think this is mostly based on the design on your API designs and the severity of the impact when your endpoint is misused. If one of your sub-sequential calls can stall the system if it is abused, I will place an IT policy or use another CAPTCHA validation as well. Anyway, I just want to point out that in your example (it may be your quick example), the password is being sent as a query string is not a good practice. URL including query strings can get logged as plain text on the web server if the logging feature is turned on (even with SSL).