对于匿名提交给API的应用程序，我应该使用哪种凭证系统？

Question

I'm creating an app where user submissions (eg photo) are designed to be captured via crowdsourcing. The app connects to an API using an API key, and the app then submits the data anonymously.

We want to avoid the overhead of people creating user accounts and passwords.

However, it seems to me this is vulnerable to a the problem of the key getting revealed. The result is that spammy submissions could be made much more quickly via browser/wget HTTP requests. Because the app is installed on people's devices, it would take a long time for us to be able to withdraw a key and replace it with another.

The approaches to deal with this problem I can think of are:

1. Hope that the key stays secret. Not ideal from a risk perspective. Using HTTPS for the API endpoint would reduce this risk, but presumably the app could still be decompiled to reveal it (not that in practice anyone would really bother)

2. Store a fixed username and password in the app, and submit as that. That basically seems to run the same problem - if the credentials are leaked then this has the same problem as 1.

3. Require a first-run fetch of a token to auto-create a username and password. However, if the key is compromised then this is no more secure. Also, this means we end up with lots of junky usernames and passwords in our database that really don't mean anything.

4. Not considered desirable: force users to create a username/password. However, that then means a lot of messing around with accounts, and compromises the anonymity of submissions, meaning data protection implications.

Are there standard patterns dealing with this scenario?

Answer 1

The first time the app runs, it could get a random token from the server, store this, and use it on all subsequent requests. The server just checks that the token is one it produced itself. After each request, block the token for 5 minutes (or make a counter so 10 requests are ok but the 11th gets blocked, depending on your use case). When a token gets misused, block it, so the user will have to deinstall/reinstall your app, or, if he made a script to emulate the app, he'd have to re-register after every few posts (plus you can limit the numer of registrations per IP or something similar).

Answer 2

You can assume any fixed credentials will be compromised. A good attacker can and will reverse-engineer the client. On the flip-side, a username/password combo will compromise anonymity (and nothing is stopping a spammer from creating an account).

Honestly, this is a very difficult problem. The (inelegant) solution involves something like a captcha where you provide a problem that is difficult for a bot but easy for a human to solve (for the record, I think captchas are almost useless, although there have been some less annoying alternatives).

Alternatively, sites like Facebook use sophisticated algorithms to detect spam. (This is a difficult approach so I would not recommend it unless you have the manpower to dedicate to it).