So much jelly in this comment. They obviously made good product decisions to get to this point. A few blips along the way will happen, when you are focusing on much more important things.
Your entire SMS history is available to any app with permissions. Most people don't even know that, or are not bothered by it. This is literally feature parity with default SMS. WhatsApp is about messaging that is simple and functional. Security is not even a main selling point.
If you want security, there are apps for that. Good luck getting your friends to use it.
Hrm. I'm torn both ways. I think a world with whatsapp is less oppressive than a world without whatsapp, even if people can spy on it, tap into it, etc- because it allows people to communicate where they previously might not have been able to. A world with secure whatsapp would, of course, be even better than a world with insecure whatsapp.
> I think a world with whatsapp is less oppressive than a world without whatsapp, even if people can spy on it, tap into it, etc- because it allows people to communicate where they previously might not have been able to.
That's a fair stance. I don't have strong feelings vis a vis WhatsApp, so this is more of a general statement :
I think the illusion of secure communication is more dangerous than insecure communication. People who think they can't be spied on will expose themselves in ways they otherwise wouldn't.
It is not a few blips. They have consistently shown to be unable to implement any kind of effective cryptography. Take this case as an example. They seem to have tried to prevent such kind of attack by encrypting the data on the SD Card with a static key. How hard would it have been to generate a random key and save the key on the internal storage?
An other example is the transport, i.e. client-to-server encryption. Even their new protocol looks like it has been hacked up by someone who learned his/her cryptography by 5 hour wikipedia reading: https://blog.thijsalkema.de/blog/2013/10/08/piercing-through... . You would think that for a market value of 19x10^9 dollar you could afford to hire a single cryptographer or IT security specialist. Especially after you have been criticized for your bad security for years.
> If you want security, there are apps for that. Good luck getting your friends to use it.
We are not even talking about difficult usability decisions here where strong end-to-end encryption has to be visible in the user interface to allow fingerprint checking. This is about the most fundamental security measures, like if you connect to your server use TLS (and check the certificate) or if you encrypt something don't use the same key everywhere.
weixiyen seems to be ignorant of, or omitted, the fact that there's a difference between "read text messages" and "read the SD card" permissions. If some Flappy Bird clone wants to read/write the SD card, maybe users don't care, but they might decide it has no legitimate reason to read their messages.
If one wanted to criticize Android for having such broad SD card permissions, there may be an argument there, but given the current state of things, it's trivial for apps to securely encrypt files they put on the SD card (they store the key in internal storage, which is much better-protected.)
The market's been sending that same message for years.
Security is a cost center and potential source of user-friction. User Data Integrity is a "nice to have". Privacy is considered only from the angle of "what can other users see through normal operation".
And that market is driven by the consumers themselves.
It sends a message that caring about your users' trust, that doing what's right for them, is for suckers.
This is not a test of "technical superiority". This is working against your users' best interests. One mistake is understandable, and sometimes forgivable, but you don't bilge it twice so cavalierly if you rank on the give-a-damn scale. (I say "cavalierly" because, as I noted elsewhere in this thread, I can't shake the feeling that this is the result of a design decision, not a technical failure.)
No it isn't 'prefer'. It's that users don't care about this kind of security in practice, they only care about the kind of security from other people in their personal lives, which is more about privacy controls than actual security.
Because of this, they get no reward from the market if they actually focus on security. Instead they focus on things the market DOES reward them for, which is being fast, never being down, being available everywhere, for the cheapest price, with no annoying ads.
They only have 35 engineers, what they could do is limited. So security becomes priority #50 like for most start ups and only a few token hours efforts are put into place. That single AES key was probably implemented 3.5 years ago.
Every security researcher goes through this phase when it dawns on them no one gives a shit about security. It leads to a few years of depression, and then going to work for people who, for whatever reason, really do care about security.
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)
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.
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/".
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.
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:
Store it in private and keep a copy on WhatsApp's server if the internal storage is lost during an upgrade (I'm assuming Android apps can't sniff each other's packets, can they?). It's not secret-from-whatsapp, they can read your messages regardless. Then the data in external storage would be comparatively safe from other apps on your phone.
Haha! But seriously given the leaked chat messages from when Zuckerberg was still not the polished CEO and less mature , your argument seems plausible.
> ZUCK: yea so if you ever need info about anyone at harvard
> ZUCK: just ask
> ZUCK: i have over 4000 emails, pictures, addresses, sns
> FRIEND: what!? how’d you manage that one?
> ZUCK: people just submitted it
> ZUCK: i don’t know why
> ZUCK: they “trust me”
> ZUCK: dumb fucks
This is actually the first time that I'm posting this, but yeah I don't fault Zuckerberg. That was one of the reasons that I added that he was perhaps less mature then. Thought processes & some beliefs change over time and I'm not saying he is the same person now that he was then.
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.
This needs to be at the top. The fix here is very simple then - prompt the user for a passphrase when doing a backup, allow no passphrase for a "friction free" if you really want to, but give the user the option.
Still, I think Google is taking the wrong approach: the insecure /sdcard partition is the place where most of the storage is in nearly all Android phones. If your app needs to store larger amounts of data, that is the place to do it. Now, there are methods to use that storage a lot more securely than this, but the way Android works really leaves developers no other option than storing this stuff on the SD card.
Google should lock down access to the SD card even more, but they'll probably cause an uproar and break many apps.
> the insecure /sdcard partition is the place where most of the storage is in nearly all Android phones.
/sdcard and /data are on the same partition these days, you should just be using the app's private folder if the data is sensitive in the slightest. Which in this case it clearly is, and it's not even large data.
Yeah I agree - increasing the size of internal storage was a blessing for my/our apps in terms of security (no more storing of secure data on shared storage due to lack of space).
Google should probabl MTP from the start and just formatted SD cards with one of the ACL supporting filesystems to get security right. But as the saying goes... it's easy to be a general after battle :)
My last gig was with a medical software company, storing and uploading physician recordings. The first thing I did in the process of building the file system component was to set up AES based off a passphrase and never let it out of memory (not safe against a rooted phone rummaging through memory, but that user's acknowledging the risks by doing so). It took me, like, a day, with tighter performance requirements than storing text messages will ever have.
But I kind of disagree with your wonderings. The problem here, isn't "base competence"--it's that it's harder to suck people into your funnel when you have frictional stuff like passphrases or verification. I cannot see an eventuality where this isn't the result of malice, where this isn't user-hateful by design. That bothers me profoundly.
I think that the problem is that "user-hateful" is the opposite of what's actually happening here: we're still at a state where security is something that users don't actually like, because it often puts the burden directly on them. Viewed cynically, what's happened here is that we have received "the software that we deserve".
As an Android developer, the real hole here is being able to read the encryption key. Jelly Bean 4.3 adds the potential for "secure key storage" which only works if the user is not smart or persistent enough to break the obfuscation through using the application itself with a debugger and a rooted phone. There is no fully safe method to store keys on a device if the attacker can gain access to the same device.
Depends on the definition of "fully safe", or maybe "device". Extracting keychain secrets from a iOS device requires brute-forcing the lock screen password.
Bruteforcing the 4-pin digit is easy "math-wise", but complicated in practice because you can't really access the data on the flash (not even dumping it, as it's fully encrypted with a hardware key), and the device will not pair to a new PC/Mac without first unlocking; so you would also need physical access to a paired PC/Mac.
For the newest devices, fingerprints can't really be bruteforced (not because of complexity, but the because the hardware locks down burning its secret after a few attempts) and Apple advises using a complex password as a fallback for the fingerprint; basically the password is the real secret for encryption, while the fingerprint hw just holds a temporary unlock secret which selfdestroys if bruteforced; this is why the user is always required to enter the password after a reboot.
Of course you might still have a 0-day root exploit to use if you're NSA (or somebody with $300K to invest), and that's where I concede the "not fully safe".
Does this happen on Windows Phone devices as well? While WP allows reading and writing to the SD card, it provides isolated storage for apps(which is a source of much pain). While I am not sure about how android handles storage for apps, there should be a middle ground where users can explicitly permit apps to read protected storage data of other apps. WP disallows storage data sharing between apps leading to limited functionality.(this is not related to the article, just a wp rant)
Any proof of that? I know there was an article about how it encrypts each message with the key of the device it is being sent to however I haven't seen anyone audit it to be sure that it isn't adding an Apple key to that list.
Since most desktops/PCs/Macs are now always online, why is nobody up in arms that any application has access to your home directory, your registry (HKCU at very least) and your "My Documents" directory either?
This is basically what Android apps have access to when requesting STORAGE permission.
No, it's quite true. If you're running Android prior to 4.1, any app can read anything from your SD card. Starting in 4.1, apps require READ_EXTERNAL_STORAGE to be able to read from the card (so user has to grant app this permission upon installation).
Have you never noticed this when you grant apps permissions? All of this is clearly written on the permissions list -- READ_EXTERNAL_STORAGE is explained there in layman's terms (as in, "this app will be able to read and write files on your SD card" or something similar).
And now, in KitKat, there have been some major changes in how the SD card can be accessed by apps, which I don't fully understand (never had to develop for KitKat only). But only a small percentage of users have KitKat installed.
If you're really storing sensitive things on your SD card, you should probably look into using some type of app for encrypted file storage (there are many on the market).
> if the user allows it to access the SD card. And since majority of the people allows everything on their Android device
1. So basically, if you're installing an app AND you're allowing the app to access all of your phone (and its dirty secrets)
2. I don't see why whatsapp would encrypt the chats (I might be very wrong on this one), isn't it better if we can access them offline through a computer if the phone crashes?
3. Bigger picture: at first, dividing permissions and asking for the user to accept them was a good idea, but now we tend to accept anything because in the end, we want to use the app. Same problem with facebook login, google login, where we tend to accept whatever info websites request just to get to the app.
There are endless good reasons for an app to request access to the SD card, so I would say it's still very reasonable to trick anybody into accepting it.
The idea of handling the SD card has a global shared filesystem that totally bypasses the application sandbox is a security disaster from the get go. Fortunately, SD cards are on the way out, and Google doesn't even bother to fix it at the system level since they're dropping it anyway at some point.
Are you in search a legitimate hacker? Do you wish to hack someone else facebook, gmail, hotmail, yahoomail, bank account without trace? Do you wish to upgrade your university score or college score without fear of been caught? Do you wish to delete some information from a website database, do you need a website? Search no more as hack word is here to give you a new lease of life. Interested persons should contact us now on this mail. firstname.lastname@example.org
I thought the way android apps can lock down information away from other apps is they are able to set permission bits to be for their own unix "user" (e.g. each app gets their own userid). It's conceivable that WhatsApp simply set the permissions to be too open.
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 compatibility.
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.
One of the great advantages of android is that it permits developers to do things like this. Let's not get upset about it when mistakes happen. Users can always choose a different app if they dislike the behavior.