iPhone to FTP – Direct Transfer or Cloud Solutions

You cannot effectively reject connections unless you supply every customer with a private key which you can individually revoke. But this is probably overkill. You don't need a bulletproof solution if most people won't bother to fire a bullet.

It's a security question, so let's describe a threat model and mitigation strategies.

Suppose you have an URL hitting which can incur noticeable cost to you (e.g. processing cost), and you want to protect it from both a simple DoS attack and from copycat apps.

Use SSL to hide the connection from being easily analyzed. Use a non-obviuos port number, a redirect sequence, a cookie exchange to complicate the connection slightly before you do the costly part of the request. Use some secret code baked into your app to let the server know it has to accept the connection.

Now someone cannot learn the expensive-to-hit URL simply by running a packet sniffer, or by looking at URL-like strings in your code. A potential attacker has to decompile your app.

You cannot really protect your code from being decompiled and / or run under a debugger. The attacker eventually learns the secret key and the connection sequence.

You notice that you start to receive rouge requests at your costly URL: either in a form of an attack, or in a form of a copycat app that has to access your service in order to run, or maybe an exploit code is publicly posted. You cannot tell a rogue request from a legitimate request, though.

Create a free minor update to your app, with a different secret key. It should hit a different costly URL that serves the same data as the compromised costly URL. For some time, make the both URLs accessible.

Watch your user base switch to the updated version. Throttle the compromised costly URL and eventually 404 it. You have just mitigated a security breach, hopefully without losing too much. Back to square one.

Disclaimer: I'm not a security expert.

The speed of downloading and uploading small files can easily be circumvented by putting several files into an archive (eventually with level 0 compression if files don't need to be compressed, which is the case for example for JPEG files). If the user uploads hundreds of files, this will result in two-three large files. If the user needs to upload only one or two files, then the speed won't matter much anyway.

The incorrect date and time configuration is the problem of the user (shouldn't synchronization be automatic on nearly every mobile device connected to internet?) Your application may verify if the time on the device is correct using NIST ITS. If, for some reason, this is impossible, use your own REST API to check if the time is correct. If the time is not correct, inform the user that the synchronization is impossible until the time is wrong, asking if he wants your app to correct the device's time automatically.

The choice between letting the app to interact directly with Amazon's S3 or using your REST API as a middle man depends mostly on those factors:

• Who owns Amazon's API keys. Are you ready to pay S3 usage for your users or do you prefer that they pay themselves directly? In the first case, the middle man API makes sense. In the second case, go with a direct connection to S3.

• Privacy, data sensitivity and legal issues. If the data is transitioning through your servers, this means that you can access it, and also means that you are uploading it to S3.

  The first point is problematic if the data is sensitive, and you may end up being sued if customers were not informed properly that the data ends on your servers instead of Amazon's (which may become even more interesting, legally speaking, if your servers are in a different country than Amazon's).

  The second point is problematic if users are uploading content which is against Amazon's policies. Imagine someone uploading child's pornography. For Amazon, you were uploading it, so you'll be the accountable person.

• Bandwidth. If your servers bandwidth is expensive (and why wouldn't it be?), you'll end up paying much more for the bandwidth than you'll pay to Amazon. More importantly, you pay twice the actual size of the files, since you are first receiving them, and then sending them.