1

Imagine the following scenario: I wish to build a photo-sharing social network app similar to Instagram (iOS only for the sake of conversation), and I want to make sure that users are using only my app to upload the photo. If it's not uploaded from inside of the app, I want to discard that photo.

Since anyone can capture the request endpoint, I imagined generating a hash that only my server can interpret. However, the hash algorithm could be found out by reverse engineering/decompiling the app.

Are there any other fool-proof concepts, or is what I'm looking for just not possible?

Thanks!

Improve this question

2 Answers 2

Reset to default
4

Short answer: Not Possible

Longer answer: As soon as you lose control of the hardware (i.e., your software is running on a phone that you don't own) you can no longer guarantee that the software talking to your server is in fact the software you wrote.

As you pointed out, there is nothing you can do to prevent the user from reverse engineering the app and finding any secrets (hashes, private keys, etc) you may have put there.

All is not lost though

All you really need to care about is that the photo comes from an authenticated user. Since your app (I hope!) is passing a server generated authentication token with every request, you can safely accept any photo that is accompanied by such a token.

In other words:

  1. User logs into the server via the app.
  2. Server replies with a token that's good for the next XX minutes
  3. App includes a copy of the token with every communication to the server

This is oversimplified, and there are tools and libraries to handle this for you.

In other words, how do you ensure that only paying customers are using your app to talk to your server? The answer to that will also answer your question about accepting photos.

Improve this answer
3
  • The token isn't as useful since the method to reverse-engineer/copy the method is same as what they already have to do(watch the request/package, copy paste it). it doesn't add any distinct steps to their process or make it any harder for them. A hashed value of a known shared value, or a generated key would be better, so that they at least would need to decompile the app to know the generating method :p Still doesn't make it very hard, of course.
    – Lacey
    May 10, 2019 at 14:16
  • @Dan Thanks for your reply. The problem is, I would like to avoid the potential usage of some 3rd-party app where my user could type in their credentials and essentially bypass this protection.
    – Stefan T
    May 10, 2019 at 14:56
  • 1
    @Lacey: The token would not be distributed with the app, but it would be created based on a secret provided by the end-user in a login procedure. To protect against replay attacks, the tokens can be one-time-use (and a new token issued after each valid request).
    – Bart van Ingen Schenau
    May 11, 2019 at 8:03
2

Actually you can't but you can try to prevent others from accessing your endpoints and etc by:

  • SSL certificate pinning. -> Prevents man in the middle and prevents others from performing a valid request to your server.
  • One time token. -> by adding some one time hash to every request, no one can just copy and paste to repeat the request from elsewhere.

These two steps can make attackers slower and much more hard work to do for them.

You should research about ISMS. There are some ways to achieve each of those security.

Hope it helps.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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