4

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?

  • You want to use email addresses as an identifier without verifying that the user owns the email address? Why use emails? Why not just let your users choose a unique username and use that as their identifier? – Ladadadada Aug 11 '14 at 11:44
  • All clients are inherently unsafe, there's nothing special about mobile phone. – Lie Ryan Nov 18 '14 at 15:11
5

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.

  • Yes, it makes sense. I think I would use CAPTCHA for an app that doesn't have a visible concept of users - only 'anonymous' users/session behind the scene but with no proper registration form with email. – MikaelW Aug 11 '14 at 17:23
  • @mikaelW what did you end up using to implement CAPTCHA in your iOS app? Thanks! – readyornot Sep 3 '15 at 1:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.