Become a fan of Slashdot on Facebook


Forgot your password?
Security Bug Communications Encryption The Courts IT

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."
This discussion has been archived. No new comments can be posted.

WhatsApp Threatens Developers of PC Gateway With Legal Action

Comments Filter:
  • I remember them! (Score:5, Interesting)

    by TheSpoom ( 715771 ) <slashdot.uberm00@net> on Wednesday September 26, 2012 @04:09PM (#41468547) Homepage Journal

    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.

  • by sinij ( 911942 ) on Wednesday September 26, 2012 @04:10PM (#41468571)

    Sadly Information Security is now more about offloading liability and then seeking damages than actually delivering secure solutions.

    • by idontgno ( 624372 ) on Wednesday September 26, 2012 @04:19PM (#41468707) Journal

      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.

  • by Anonymous Coward

    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)

    by DMiax ( 915735 ) on Wednesday September 26, 2012 @04:52PM (#41469215)

    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.

    • by Nerdfest ( 867930 ) on Wednesday September 26, 2012 @05:49PM (#41470021)

      Apple did the same thing.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      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

  • by KarlH420 ( 532043 ) on Wednesday September 26, 2012 @05:14PM (#41469547) Homepage
    If WhatsApp doesn't add more security, my prediction, is we will start to see WhatsApp spam. If you know phone number and it's IEMI you can fake the sender using the WhatsApp protocol. All it will take now is someone to acquire a database of IEMI's and the phone numbers before the spam can start flowing.
    • by Anonymous Coward

      OR you can pack such "feature" into an avalanche of boobs screensaver apps (and the like..)

  • I only have open computers, how do I set up an account?

  • by jtara ( 133429 ) on Wednesday September 26, 2012 @10:08PM (#41472789)

    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 ( [] ) 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.

    • Not possible, given your requirements. You will need to choose between relying on the deprecated UDID, lack of a perma-ban abilty (token generated on install), or requiring a login.

To do two things at once is to do neither. -- Publilius Syrus