Hacker News Reader

Comment by kllrnohj | Hacker News Reader

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 this is)

View on HN

Even better than the app's private data folder, use Android's KeyChain API to store the key in hardware-backed credential storage:

http://developer.android.com/reference/android/security/KeyC...

This API wasn't available until Ice Cream (4.0). I don't know WhatsApp user makeup, but I wouldn't be surprised if this "system" is a holdover of what was available to them in Eclair.

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.

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/".

OS X doesn't have that problem when using sandboxed applications. I choose to opt out by installing non-sandboxed applications, but I know that I'm doing so and I don't install non-sandboxed stuff from people I don't trust. I also have much more accessible tools for inspecting the behaviors of applications, should I want to do so, on OS X than Android - I can do my own homework if I have a notion. (I don't expect end users to do so, but the option is there.)

And Android external storage is explicitly not for sensitive, in-the-clear data. Ever. It doesn't matter what Google "should have" done. They documented What Not To Do, and then WhatsApp went ahead and Did.

For what it is worth, I wasn't interested in a privacy debate, but rather technical advice.

I have come to the conclusion after a bit of research, the only way to make this backup work is to require a passphrase, or for the OS to provide sandboxing. Android 4.4 provides the necessary sandboxing. I am sure WhatsApp will use it.

I don't agree with WhatsApp's choice to not require a passphrase, but I at least understand their thinking. They chose frictionless backups with the risk that malicious apps would be able to read you text messages. That is not the choice I would like, but it is not a choice made by an invertebrate.

Hacker News at times reminds me of this scene from the Princess Bride:

http://www.youtube.com/watch?v=18ulbI9k5eA

It is a choice made by someone prioritizing user acquisition over treating users fairly, and there's no defensible argument for that.

> Google should have figured out how to let applications sandbox data on the SD

It's called put your data in /data. You get a private app data folder by default. /sdcard and /data are both internal storage on the majority of phones, neither points at a physical sd card slot.

And seriously, who wants their messages stored on /sdcard anyway? You pop out the sdcard and all your text messages vanish? What kind of brain dead decision is that?

Reading the article, the data the "exploit" looks at is only if the user has turned on the backup feature (disabled by default).

The backup feature is on by default, scheduled to backup at 4:00 daily. I can't find an option to turn it off.

I think the widespread practice of Android applications storing potentially large data in /sdcard dates to a time when /data was extremely small on most phones, and would fill up quite rapidly if you had a large number of applications installed. I don't think that's the case any longer, at least certainly not for an SMS app.

>app's private data folder

That may be the problem. WhatsApp has focused since the beginning on making their app available on as many devices as possible (They even have symbian compatibiity).

My WhatsApp database is almost 500MB, this is more than many low end Android phone's internal memory. Therefore, they decided to store the database on the SD card.

I don't think that this should be a problem had they decided to implement proper encryption on the database.

I'm not an expert and this is just pure speculation, so please, take as it is.

Did you read the post? You only need to store the key in private data. A few bytes at most.

Yes, I did, I wouldn't be replying if I hadn't. But I was replying to the parent comment.

>Which is where the database should have just been stored in the first place, and not on the public SD card

I was just guessing why WhatsApp may have decided to put the database on the SD card. But maybe I didn't understand what kllrnohj was referring to when he said "database".

EDIT: Also, that's why I said:

>I don't think that this should be a problem had they decided to implement proper encryption on the database.

The key should be in the private data folder, the database belongs on the public sd card since it gets very large.

Reply on news.ycombinator.com