iPhone Distributed Computing Fallacy #4: the network is secure

Reviewing the 8 classic “fallacies of distributed computing” and how we can avoid them when writing iOS applications.

The fallacies of distributed computing

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn’t change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.

Fallacy #4: “the network is secure”.

Any network service needs to consider security as part of its design and services built for use by iOS applications are no exception. All of the basic attacks a web service needs to consider still apply; session hijacking, stolen credentials, code injection, and so on. Securing a web service is a much larger topic but let’s consider a couple of areas specific to iOS client applications.

User’s devices are only as trustworthy as the users themselves. Anyone with a copy of your app can inspect both the contents of your application’s bundle and the traffic it sends. Don’t rely on your app storing a shared secret (credentials to access your web service, certificates, encryption keys, and so on) without revealing it to your users.

UDIDs are unfortunately a poor mechanism for user authentication. They are convenient as a unique identifier available without needing to walk users through any sort of account creation and I’ve worked on apps which use them as a temporary form of identification but they don’t work well as permanent identifiers. UDIDs are effectively user provided data and can be changed; either deliberately which might allow one user to masquerade as another or unintentionally when a user upgrades their device or installs an app on a second device. A UDID identifies a device, not a user.

Mobile devices are even more likely than general web traffic to be used on public access points and networks which can easily include malicious users. Any data your app sends in the clear can be read by other members of the network. If you or your users consider that data sensitive it really needs to be sent over an encrypted connection. Apple provides the Advanced URLConnection sample application which demonstrates establishing connections using http basic auth, and certificates (including self-signed certificates if you want to issue your own for your web services).
As a simplistic example a NSURLConnection can support https requests with the addition of just two additional delegate methods.

- (void) httpsConnection {
    self.connection = [NSURLConnection connectionWithRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"https://encrypted.google.com/"]] delegate:self];
    [self.connection start];
}

-(BOOL) connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
    return [protectionSpace authenticationMethod] == NSURLProtectionSpaceHTTPS;
}

-(void) connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
    if ([challenge previousFailureCount] == 0) {
        if ([challenge proposedCredential] == nil) {
            NSURLProtectionSpace *protectionSpace = [challenge protectionSpace];
            SecTrustRef trust = [protectionSpace serverTrust];
            SecTrustResultType trustResult;
            SecTrustEvaluate(trust, &trustResult);
            if (trustResult == kSecTrustResultProceed) {
                NSURLCredential *credential = [NSURLCredential credentialForTrust:trust];
                [[challenge sender] useCredential:credential forAuthenticationChallenge:challenge];
            }
            else {
                [[challenge sender] cancelAuthenticationChallenge:challenge];
            }
        }
        else {
            [[challenge sender] cancelAuthenticationChallenge:challenge];
        }
    }
    else {
        [[challenge sender] cancelAuthenticationChallenge:challenge];
    }
}