TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

GM the app gets hacked a few days after testflight release

2 pointsby wilshiredetroitover 3 years ago

1 comment

MrWifflesover 3 years ago
TL;DR - apparently this was some form of &quot;meme&quot; app that let people say &quot;good morning&quot; to each other. They found out Wednesday morning (US Eastern time) that somebody had obtained unauthorized access to their user&#x27;s data. They <i>think</i> the attacker obtained sensitive access credentials by decompiling the iOS app and pulling it out of there. As a result, they&#x27;re realizing a small team not making any real money on an app that was intended to be a joke isn&#x27;t capable of responsibly managing infrastructure and security, and are taking the understandable (IMHO, responsible) action of shutting it down.<p>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, &quot;well that&#x27;s stupid, why are you putting access credentials for the infrastructure inside the app itself?&quot; But that&#x27;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&#x27;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.<p>It sounds like they did something stupid here, but I don&#x27;t see how else they could have done this short of individualized user accounts. I don&#x27;t know what good reason they&#x27;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&#x27;t a massive facepalm in the basic design of the app itself, how <i>else</i> could they have done this securely?<p>Clearly I&#x27;m missing something here. I&#x27;m not a mobile app developer so there are likely best practices for these situations I&#x27;ve just never heard of. But I just don&#x27;t see a way to store &quot;global&quot; (not-unique) access credentials to a resource securely in a distributed app (assuming there&#x27;s a good reason to do that of course) that wouldn&#x27;t be vulnerable to this exact same attack vector.<p>What should they have done differently?