No way anyone else at FB could have built this app and given it away for free for years for that price.
No way. Totally worth it. 19bn $.
Sequoia's deck on the amazing sclaing of 32 devs supporting that many users? well, guess what, they did it through taking shortcuts. Who would have guessed. Totally flabbergasted.
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.)
>They obviously made good product decisions to get to this point.
Which is the problem with this kind of "market". It's basically theft, yes, stolen merch does sell well. Join the game, this is how the rules are played, take a page from the CIA's book. Have fun!
It's also a highly-simplified backend. No multisession (synchronization is hard), no back-end message history searching (search and graphs are hard).
They took a lot of shortcuts, which turned out really well for them. Simplification made for a very fast client and a low-latency, low-bandwidth protocol.
Being slim to deliver only essential functionality is one thing, but playing fast and loose with user data is not a shortcut that should be rewarded so lavishly.
Not exposing a client-facing search service has no bearing on their ability to search through your messages on the server; they most assuredly can search through your messages.
What's troubling is, that their security track record has been abysmal from the start. In that regard, the acquisition sends entirely the wrong message.
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.
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 this is)
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/".
> 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?
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:
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.
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.
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.
One might think Facebook did their due diligence and said, "DANG, you got all these users with this big of a hole just laying right out there? Here, have some money."
Haha! But seriously given the leaked chat messages from when Zuckerberg was still not the polished CEO and less mature [1], 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.
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...
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.
This is true on Nexus phones, but it's a mount point (not "emulated") on Samsung or other SD-card-equipped phones, which I think--not sure--is more of a majority.
No, on Samsung & other SD-card-equipped phones /sdcard points to internal storage and there's some other path, like /sdcard2, that points at the actual SD card.
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)
Google switched to the isolated storage model (on the sd card) for KitKat - http://source.android.com/devices/tech/storage/. Google has content providers so if an app wants to share data it can do so https://developer.android.com/guide/topics/providers/content.... If you really want to do something unsafe like allow direct file access to any folder then that is a reason to root your Android phone. Then using an app like SuperSU your can grant root permission to an application.
If they put the database in their isolated storage then no. Apps are sandboxed to their own isolated storage folder and cannot get access to the other apps folder (the source of your pain)
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.
From the title I thought the current database. But it's just the by default daily created backup.
I remember writing a rooted script for Tasker to get the actual messages to my pebble, since WhatsApp still doesn't expose them through their notifications.
I fired an SQL query to their sqlite database everytime a notification from WhatsApp came in to see what the new message actually contained.
wait a second...my SD card folder contains a folder called DCIM which includes all my camera photos... are you suggesting that all my images are available to any app that includes SD card permissions?
Yes. There is no way on Android to give fine-grained directory-based access permissions (unfortunately). So all SD card permitted apps can read the SD card globally.
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)[1].
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).
Unless I'm mistaken, any application can read the device's SMS database if given the appropriate permission (and few users are very discerning with regards to permissions).
To an end-user, WhatsApp is essentially an SMS application, except it doesn't use SMSs. Given that, this doesn't seem like the end of the world.
WhatsApp claims to keep your texts secret, and this is a big selling point. They make privacy claims that go beyond normal SMS messages, and that's why this is a big deal.
I've been using WhatsApp for years and seen many selling points, but security has never been one. A link would help because I've never gotten the impression that they were trying to sell security.
huh? Stop making shit up. None of what you said is true. They were sending messages in plaintext not that long ago. Their switch to encrypted communication was merely a footnote.
> 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.
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.
Sure - consumers get to decide what tradeoffs they want, and the media assists by exposing information that might not be otherwise available, as is happening here.
OT, but AES write(decrypt(open())) in python as done on the post seems to be padding the decrypted data with extra bits to match up in size with the source.
OpenSSL's aes-192-ebc gives me a slightly shorter, but well-formed db.
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. [email protected]
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.
It does seem bizarre they don't make any ACL on external storage. I am sure this is not a strange isolated report. This problem must have been known for years both externally and internally.
On the side note, from old news I remember Google is indeed pushing forward with Chrome-brand, specifically Chrome OS.
Because people want to take their SD card, plug it in somewhere else, and have access to their photos / videos / songs. This necessitates using FAT. That is the case for most removable media.
This is actually ridiculous because having this much largest app in android market and this type of bug can kill all of their audience.... must have to aware from now..
No way anyone else at FB could have built this app and given it away for free for years for that price.
No way. Totally worth it. 19bn $.
Sequoia's deck on the amazing sclaing of 32 devs supporting that many users? well, guess what, they did it through taking shortcuts. Who would have guessed. Totally flabbergasted.