Preventing Illegal Access to Webservice

Question

Let me start off by saying that I read other StackExchange questions related to this and they weren't really able to answer my question. I have a feeling this may be an unsolvable problem, but I'm wondering if maybe there's a happy medium that will satisfy my requirements.

I have an Android application. However, it's not login-based in the traditional sense that users don't sign up with an email or anything. We just automatically create an account for them with some randomly generated UUID as their "login" to the service. To get this UUID, the Android application sends a request to a webservice indicating that they are a new user who just installed the application. The webservice then returns a UUID that will be used for any further accesses to the application. The point of this is to make it so that user specific information can still be stored in the database, but users don't have to go through the hassle of creating an account and logging in every time.

Obviously, requests to the webservice for other actions are all restricted by having a valid UUID. However, the webservice for creating the account has no restrictions, meaning an attacker could spam GET requests to it from any device to create any number of users they want and flood the database/server.

My question is, how can this be avoided? I understand the concept of a secret embedded in the Android application to access the webservice, but it seems like any client-generated secret could be easily obtained by an attacker by decompiling the APK. Another idea was to restrict access by MAC address, meaning only MAC addresses with the app installed could reach the user creation web service URL. But because of MAC-spoofing, that also seems like a bad idea.

Is there a good way to have a client-generated secret that isn't easy to obtain by examining source code? I know this is a very difficult question but if anyone has some insight that would be great.

Answer 1

However, the webservice for creating the account has no restrictions, meaning an attacker could spam GET requests to it from any device to create any number of users they want and flood the database/server.

My question is, how can this be avoided?

You can use a mix of CAPTCHA and IP restrictions to avoid such type of attack.

IP restrictions:

An unique IP can create a maximum of X accounts in an Y amount of time (Y seconds, or minutes, or hours, or days, etc., just you can balance the right amount).

CAPTCHA:

CAPTCHAs are commonly used in an effort to prevent automated account sign up, then you can require a CAPTCHA challenge-response to create an account.

Mix CAPTCHA and IP restrictions and you are done.

Is there a good way to have a client-generated secret that isn't easy to obtain by examining source code?

I didn't understand your question.

1) If you want to protect your server just against flood, the answer is above.

2) If you want to protect the user data, so nobody can send requests to your server to get the informations of user with UUID X, you can create a random token specific to an UUID when creating the account and can store it in a encrypted database on Android.

EDIT:

See the new "No CAPTCHA reCAPTCHA”.

http://googleonlinesecurity.blogspot.com.br/2014/12/are-you-robot-introducing-no-captcha.html

Painless for your users, effective to you.

Answer 2

However, it's not login-based in the traditional sense that users don't sign up with an email or anything. We just automatically create an account for them with some randomly generated UUID as their "login" to the service.

If you are just allowing ANY user to create an account with your application, without providing any personal information, it is very likely that your application is going to be spammed with a large number of requests to create new users.

The point of this is to make it so that user specific information can still be stored in the database, but users don't have to go through the hassle of creating an account and logging in every time.

Actually, this a bit confusing. What exactly is this user-specific information? Where did it come from if the user never signed up with your app? If it is something unique such as an email id or phone number mapped with the user assigned UUID, then this unique information can be used for a simple Challenge-Response authentication, which can essentially stop the scam. The fact that your application is allowing users to sign-up, without providing any personal information (which is unique and can be used to authenticate that user in the future), makes your application vulnerable to such spamming attack.