Any Android app can read your WhatsApp database

Post by bentcorner » Tue, Mar 11, 2014, 6:30 PM UTC

dermatthias wrote: post #35

izacus wrote: post #5

Storing critical data to external storage (which is clearly explained as unsecure in http://developer.android.com/guide/topics/data/data-storage.... ) is a huge security hole. This kind of basic oversight makes me wonder about base competence of WhatsApp developers - anyone with basic understanding of the OS would get that anyone can read external storage.

One important point here: In the article the author says that the location of the database is /sdcard/WhatsApp/Databases. That's not entirely correct. It only gets copied there when you use the build in backup feature (Settings -> Chat Settings). Else, it sits "safely" under /data/data/com.whatsapp/databases like every other Android sqlite database. But nonetheless, WhatsApp was and is not really known for its safety…

Post by jcampbell1 » Tue, Mar 11, 2014, 6:33 PM UTC

eropple wrote: post #37

jcampbell1 wrote: post #33

Earlier quoted context omitted.

I don't think you are evaluating the tradeoff at all here. WhatsApp won by making a friction free experience. You are adding email and pass phrases, or any one of the dozen things that make it harder to use. I accept there is a good solution, but I don't think you are thinking about the problem broadly.

There is no "tradeoff" here for a reasonably vertebrate hominid. When you demand user trust, security is core. If it's not core, go home because you cannot be trusted to make adult decisions. The people using your software are more important than your fucking term sheets, man.

Post by css771 » Tue, Mar 11, 2014, 6:35 PM UTC

Pxtl wrote: post #29

izacus wrote: post #7

Earlier quoted context omitted.

Em, no - that can only be done in internal store "data" directories which are usually formatted with UNIX filesystems and are by default secure (and cannot be accessed by other apps at all). WhatsApp is storing to external (on most devices FAT) storage (which was SD card on older devices, it's usually a separate directory/partition on newer ones) which does not have any ACL-like system due to FAT backwards compatibil…

Honestly, the more I tinker with Android, the more I'm terribly disappointed in Google. I mean, around Android 2 we were all excited by the potential of a first-class big-money supported open-source OS to really shake up the industry. It had so much potential. Now? Well, it still has a lot of potential. Even Google seems kind of embarrassed by it, compared to the Chrome brand.

Post by eropple » Tue, Mar 11, 2014, 6:37 PM UTC

jcampbell1 wrote: post #43

eropple wrote: post #37

Earlier quoted context omitted.

There is no "tradeoff" here for a reasonably vertebrate hominid. When you demand user trust, security is core. If it's not core, go home because you cannot be trusted to make adult decisions. The people using your software are more important than your fucking term sheets, man.

You do realize all desktop software has this same vulnerability. I think you are being a tad hyperbolic. WhatsApp has some blame, but Google should have figured out how to let applications sandbox data on the SD card without having to do roll your own AES key management system. It could have been as simple as put the data in a folder named "private/appname/".

Post by josu » Tue, Mar 11, 2014, 6:42 PM UTC

kllrnohj wrote: post #25

jcampbell1 wrote: post #19

Earlier quoted context omitted.

Just out of curiosity, where would you store the unique AES key, that wouldn't break the UX in many ways? For instance, not losing messages when you upgrade your phone.

Storing the key is easy, you put it in your app's private data folder. Which is where the database should have just been stored in the first place, and not on the public SD card. You could also have a user-supplied passphrase with email recovery. Or any of a dozen other best practices that exist. This isn't exactly a new problem, there are plenty of solutions that are far superior to rot13 (which is basically all thi…