But this begs the question: if indeed access credentials were obtained by decompiling the iOS app, that means said credentials were IN the app in some form to begin with. My next thought was, "well that's stupid, why are you putting access credentials for the infrastructure inside the app itself?" But that's just it - short of individual user accounts and storing credentials unique to only that user on the device, how else would you store credentials used to access a public resource inside an app? You could encrypt them with some kind of key pair, but even then you'd still have to distribute the decryption key along with the app so it could decrypt the data in memory, so that would only present just one more step to the attacker in this scenario.
It sounds like they did something stupid here, but I don't see how else they could have done this short of individualized user accounts. I don't know what good reason they'd otherwise have for storing global access credentials inside the app other than for accessing a public resource, but clearly they had SOME reason to do this. Assuming this wasn't a massive facepalm in the basic design of the app itself, how else could they have done this securely?
Clearly I'm missing something here. I'm not a mobile app developer so there are likely best practices for these situations I've just never heard of. But I just don't see a way to store "global" (not-unique) access credentials to a resource securely in a distributed app (assuming there's a good reason to do that of course) that wouldn't be vulnerable to this exact same attack vector.
What should they have done differently?
