WhatsApp Threatens Developers of PC Gateway With Legal Action 27
An anonymous reader writes "In an apparent reaction to the security vulnerabilities demonstrated by The H's associates at heise Security, the company behind WhatsApp Messenger is taking action against the developers of a library of functions for using the WhatsApp service via a PC. The developers have responded by removing the source code from the web. However, the popular texting alternative WhatsApp still has a major security problem. Attackers can compromise other users' accounts with relative ease, and send and receive messages from another user's account. Forked versions of the code are still available on Github."
I remember them! (Score:5, Interesting)
One of our clients wanted us to send notification messages over WhatsApp to end users, but they don't have an API and at the time, this third party library was not available. We told them we couldn't do it. Sounds like we avoided a shitstorm.
Re:I remember them! (Score:5, Insightful)
Also, let's just all act like github isn't versioned [github.com]. *whistles*
Re:I remember them! (Score:4, Informative)
git clone git://github.com/venomous0x/WhatsAPI.git
cd WhatsAPI
git checkout 476bb7a0d2d4def370c876a8557542ee21686f7f
Re: (Score:3)
Or if you don't actually need to do a git clone, just hit the ZIP download button in the top left.
Re: (Score:1)
We told them we couldn't do it.
Good. Did you implement using plain old SMTP or XMPP instead?
I have no idea why SMS and its clones haven't died yet. Just send a frickin' e-mail...
Re: (Score:2)
In Hong Kong it's so common that if you want to book a van the driver asks you to send the address by Whatsapp. Well, I'm one of those that does not have Whatsapp, and being able to use it to send messages from a PC sounds perfect to me.
So what's the big deal with being able to do it from a PC? It's not much more than an IP-phone and instant messaging type of app, isn't it? Or am I missing something really important here?
Liability Assurance... (Score:5, Insightful)
Sadly Information Security is now more about offloading liability and then seeking damages than actually delivering secure solutions.
Re:Liability Assurance... (Score:5, Interesting)
From a business ("risk management") perspective, it often costs no more to offload liability or otherwise mitigate the impacts of a security event than to actively prevent the security event. In that case, is anyone surprised a business makes a business decision? If you ask the business, security features support the business and not the other way around, so business priorities always take precedence.
And yeah, that means that if there's a breach, if you can decrease the overall cost of notification and settlement with the victims, letting the breach happen may be the more business-savvy choice.
Sucks, but that's the profit motive for you.
Nut job (Score:1)
But this app is alikely school project turning into a multi-million dollar business against the odds. I mean, couldn't these guys at least hire someone to think about security and authentication? Or are they only worried about spending their cash on ferrari's, champagne and hookers?
Bunch of crackpots (Score:4, Interesting)
Few developers make me so angry as WhatsApp's ones. They just took XMPP, made a couple of changes so that it does not work with normal clients, forgot about any kind of security and call it a day. Their biggest idea is using phone numbers as identifiers and marketing their app as an SMS replacement instead of an internet chat. Fuck them.
Re:Bunch of crackpots (Score:5, Interesting)
Apple did the same thing.
Re:Bunch of crackpots (Score:5, Informative)
Yeah but with SIP instead of XMPP (FaceTime).
Re: (Score:3)
iMessage.
Re: (Score:3, Interesting)
Few developers make me so angry as WhatsApp's ones. They just took XMPP, made a couple of changes so that it does not work with normal clients, forgot about any kind of security and call it a day. Their biggest idea is using phone numbers as identifiers and marketing their app as an SMS replacement instead of an internet chat. Fuck them.
Yeah, the big thing about it is using phone numbers as identifiers. But even that doesn't justify the security holes. They could just generate a random key and store it on the server and on the device. So, the phone number would be the "username", the random key would be the "password". If the user changed device, the current SMS verification can be used to verify the user is really using the same phone number, and then issue a key regeneration. There is no excuse to use some predictable number based on pub
WhatsAPP spam comming (Score:4, Insightful)
Re: (Score:1)
OR you can pack such "feature" into an avalanche of boobs screensaver apps (and the like..)
How to initiate with no curated computing devices? (Score:3)
I only have open computers, how do I set up an account?
OK, so what's the RIGHT way? (Score:3)
Hehe, good timing... Good opportunity to pick some brains...
I happen to have an iOS app under development that uses XMPP for a specific use case. It primarily uses MUCs, and I want users to be anonymous, and don't want users to have to deal with sign-up. I haven't really given it much thought, beyond realizing that there are some pitfalls, and that I want to avoid them.
At the same time, I do want users devices to be uniquely-identified, because I realize that it will occasionally be necessary to ban users, and I don't wnat them just signing back up. I think the the cost of a new device is a reasonable deterrent to bad behaviour. ;)
I'm using ejabberd for the server. The client is written on the Rhodes mobile platform (Ruby Rails-like embedded server, HTML/CSS/Javascript/jQuery Mobile for UI, and, yes, before you say anything, I actually get great near-native performance out of this. I've had to become an expert at getting performance out of JQM in the process... (This mostly involves using as little of JQM as possible...) The Ruby code and simple Ruby ORM over SQLite is blazing fast compared to JQM, BTW, it is absolutely not a bottleneck.
I'm using my own fork of XMPP4R ( https://github.com/watusi/xmpp4r [github.com] ) that has some minor mods for Rhodes, as well as a BOSH module that actually works. (Yes, BOSH latency sucks. Hopefully, it will just be a fallback for getting through firewalls, but I am also concerned with connection drops on mobile devices being an annoyance in the MUCs. I don't really want to write my own connection manager for regular connections, since I have no Erlang experience...)
So, I'll be using standard XMPP, a standard server, SSL-encrypted messaging with perhaps a fallback to non-SSL for firewall issues. (Need to make sure user is aware when that happens, though.)
I do have two issues to solve that will take some server-side work. One seems fairly trivial: the app needs to be able to request creation of a MUC. The server will do a validity check against a list (MUCs aren't arbitrary, but I don't want to create them in advance. Imagine that the name of the MUC has to be a kind of fish) and create the MUC and give ownership to admin. (Yea, right now the app itself creates the MUC in demo, as the test server allows anybody to create one.)
The other is how to "bootstrap" the creation of ID/password, or some other authentication mechanism. All I really care about is:
1. I need to be sure that only my app is making the request for a new ID.
2. If at all possible, I need to be sure that the same device will always create the same ID. (So users can be banned when necessary.)
Basically, if you own the app - the real app and not a clone or jailbreak - you get to create one and only one ID per device. (Ok, maybe jailbreak too, because that will take away one reason for people poking around inside.)
The app is meant for casual and anonymous communication, but the thing is, you never know what applications people will find for it. (Actually, there are many scenarios for serious use.) So, I'd like to provide reasonable security.
I know I can't use a UDID, since Apple has banned their use. (And now it's a private API.) I am dubious on using any other hardware-related ID, because Apple might ban them in the future. I could use an Application UDID, but then the user just needs to delete and re-install the app to get a new ID.
For the problem of insuring that only my app can make a valid request to create a user, I figure I have to sign a message with some well-burried key. (Yea, yea, I know, that worked well for satellite receivers...)
The Ruby code is compiled to Ruby bytecode, so it won't be easy, but certainly not impossible to try to find it in code. (Of course, I wouldn't just code-in a simple constant.)
I'd love to hear some suggestions on how to do this the right way.
Re: (Score:2)
Re: (Score:2)
FWIW I would require a login.