Piercing Through WhatsApp’s Encryption
blog.thijsalkema.de
blog.thijsalkema.de
But using the same RC4 key in both directions of an encrypted transport isn't just a bug known in the 1990s; it is the emblematic cryptographic attack of the 1990s, the one crypto flaw that even non-crypto pentesters could reliably deploy. For instance, bidirectionally shared RC4 keys broke the Microsoft VPN scheme, a bug discovered by Peter "Mudge" Zatko when there was still a L0pht Heavy Industries.
So my point is, this is a bit sad.
I should add, recycling the keystream of a stream cipher is worse than he makes it sound. The attack he's describing is called "crib dragging" and implies that an attacker has access to plaintext. But attackers don't need access to plaintext to attack repeated-key XOR, which is what a set of ciphertexts encrypted under the same stream cipher keystream works out to be.
Ignorance? Lack of research? Lack of industry best standards?
This seems to keep happening all the time.
Although most programming in general is full of hackery and rookie code used in production. So that itself isn't alarming. I'm just curious if it's the security industry itself is particularly in need of better communication of best practices and things to avoid.
Maybe more work with designers/writers to create online guides is needed.
They probably record every single message too since storage without transmission is cheap and avoids a class of bugs with deletion. The stored histories could become a business advantage later to mine chat histories for marketing and advertising data like facebook, twitter, google and everyone else. They say they charge now to avoid a marketing driven approach, but cable TV has made similar promises in it's starting days too.
Also they run on such platforms as blackberry, nokia s40 devices, windows phone and symbian where plopping in some C crypto library probably wasn't practical. From what I know, most crypto libaries are written in some C family language or you have bouncycastle for java. Everything else is relatively obscure or broken. So something they could roll by themselves might of been what they have to choose from.
For many companies, security is something you do the motions for like you would with government paperwork and compliance, not necessarily because it's important to you. Unfortunately the average person only cares about door lock security, not real crypto secured products.
I think these news and concerns often don't make their way to a bulk of their users, who probably aren't very tech savvy. If they don't see any user defection as a result of these issues being uncovered, then I'm not surprised about their lax stance on security.
When you are not viable as a business new features or begrudgingly addressing the huge amount of technical debt you generated in your early days so you can deliver new features faster is what you focus on. WhatsApp will only address security when it threatens the viability of their business, which by that time will probably be too late.
The thing is, there is no such thing as a security industry that would be interested in pushing such best practices. It's a little bit like occupational safety. There are companies that sell hearing protectors, i.e. solutions to some specific aspects of occupational safety, just like there are companies selling firewalls to protect against some specific aspects of IT security. But you cannot sell one product to protect against all IT security threats that emerge in a software company as there are security concerns in every aspect of an IT product. On the server side it is about protecting the user content against outside threats (firewalls, SQLi, password hashing, log protection and redaction, strong SSH logins, DoS, etc), on the protocol side it is about authentication and encryption (MITM attacks, content separation (think about the beast attacks), strong crypto, using the right crypto for the job, DoS), on the client side it is about folk security models and social engineering (strong passwords, password resets, two factor authentication, social engineering, UI design).
Occupational safety on a construction site has to be considered by every worker and in every part of the construction. IT security is just as much pervasive to software engineering. You think implementing a search feature for your website is not security sensitive? You might just have compromised your user login because of cross site scripting. Logging debug information is harmless? Not so much if your database password is output to the user in case of a poorly written exception filter. Heck, even simply storing some user data in a dictionary can be the cause of a DoS [1].
Basically what I saying is that IT security is not the responsibility of some specialised security industry, but of the whole IT industry.
[1] http://events.ccc.de/congress/2011/Fahrplan/attachments/2007...
https://class.coursera.org/crypto-preview/lecture/6
https://class.coursera.org/crypto-preview/quiz/attempt?quiz_...
Is it that much to ask that a company that large performs a security audit quarterly?
Unfortunately, it appears that you are not at all doomed if you don't know security well. I say "unfortunately" because I'd rather have fewer secure products than the massive array of insecure products we enjoy today.
I think it's kind of like cars and the corresponding (lack of) traffic & vehicle safety rules a century ago: right now it's everybody for themselves, but what you really need are rules that encourage those in a position to cause improvement to actually improve.
Developers like us and firms that employ them need to be liable for security exploits - preferably with good enforcement with many small fines rather than a few "examples" that get the book thrown at them. And hackers, even if dubiously motivated, shouldn't be driven underground by punitive measures because that causes a really unhealthy head-in-the-sand dynamic.
What's harder is systems security, which you can't just abstract away into a library.
Maybe it is people's false expectations, that what ever I send with my smartphone is secure.
So yes, clearly security is just not a priority for that product.
1. You are not smart enough, so don't try to be clever. 2. Use off the shelf audited tools, implementations and protocols.
And that is ... while I admit that there is chance for "any crypto product/expert to be compromised" I distrust my brain to get everything right way more than that.
*Disclaimer - good enough for ensuring sexted stuff remains private, not good enough for nuclear launch codes.
Absolutely not. WhatsApp has a history of poor security yet it is a wildly successful startup.
Everyone should know the basics, and should know enough to know when to consult someone else or learn the not-so-basics. They should also know the key rules:
* Security should never be an afterthought unless you are doing proof-of-concept development and even then as soon as you move from PoC to prototype/alpha then relevant security should be baked in to the design
* Relevant is the key word above. Everyone should know when security is needed/desirable. Not being aware that bad security is a problem is not acceptable these days, if it ever was
* Don't try be clever and roll your own
* Don't be lazy or NIHy and roll your own because you have trouble integrating with something else
* Get someone else to review the design and code occasionally, how-ever informally - mistakes will be made, particularly in security, and finding your own is sometimes more difficult than finding someone else's. Also your users won't find security issues like they will easily spot functionality ones.
* Don't claim any security claim that you can't definitively back up. You make the rest of us developers look bad when you get called out on the matter.
* Better still, make sure that your users know where your security is intentionally lacking ("this is not designed as an NSA secure service, we do not encrypt data server-side, if you are storing a secure document here encrypt before sending" or such).
* Absolutely everyone who implements something that needs to authenticate a user needs to know what good password handling is, even if you use third party services for authentication you need to understand what is going on in order to judge if a given third party is good enough at what they do.
> It really gets in the way of just making things and putting them up; I think kind of kills the spirit of creation and entrepreneurship.
If what someone is just putting up" is something that holds personal or otherwise sensitive data, then I don't think this is a bad thing. If they are collecting that sort of thing (actively or passively) then they should be careful about it or should reconsider doing it at all (or should warn their users that what they are "just putting out there" is not production ready yet so may not be secure).
Of course if you are not doing anything with sensitive data these requirements reduce greatly. If you are doing anything that require authentication then you still need proper auth handling code no matter what though.
> Are you doomed to fail at the startup game if you don't know security well?
If your startup handles personal or otherwise sensitive data you should be, if by "startup" you mean that you intend to make a living (or just make a name) with what you are doing. This sounds harsh, but that is just the way it is. The world is harsh.
But, if you are a startup, just starting I mean, I don't think you need to be a security guru at all. Whatsapp started sending messages in plain text and look how many users they got. That's because users didn't matter about security until the company was so big that security became a real threat.
Screenshot: http://i.imgur.com/wY2zDl7.jpg
Source (German): http://stadt-bremerhaven.de/server-von-whatsapp-gehackt/
Granted, RFC 3962 does MAC-then-encrypt. This is being addressed in draft-ietf-kitten-aes-cbc-hmac-sha2.
I can't see any reason in the world to adopt GSSAPI. I strongly recommend that nobody else do so.
It was just a suggestion. Feel free to roll your own!
Google search: "cryptography answers" :-)
---
And I just realised who I am replying too, off course you know this.
* Hottest 'cryptography' answers [stackoverflow.com]
* Hottest 'cryptography' answers [bitcoin.stackexchange.com]
* 'cryptography' Answers By New Users [bitcoin.stackexchange.com]
* CISSP Exam Cram, Second Edition [safaribooksonline.com]
* CEH® Certified Ethical Hacker Study Guide [safaribooksonline.com]
* CISSP Rapid Review [safaribooksonline.com]
I think you wanted to suggest searching for [cryptographic right answers]. But of course, nobody will search for that.
To be honest, I'm not surprised.
Then they just have to google to get the latest TLS best practice cipher suite settings etc.
People shouldn't be using crpyto libraries directly; they should just be using TLS to talk client-server, and then its just a configuration problem, not a code problem.
And think how much time they'd have saved too :)
https://class.coursera.org/crypto-008/class
> Will it be Open Source?
> We have all intentions of opening up the source as much as possible for scrutiny and help!
But it's not done yet.
I'm shocked that a startup with a similar approach to WhatsApp hasn't made a reasonable rigorous application yet.
Equivalent to cc'ing the NSA.
Whatsapp - broken encryption Google Hangout - NSA Texts - NSA (and others) Facebook Messenger - NSA iMessage - probably NSA, though I don't know.
and so forth. Most commonly used text services are woefully leaky.
It's rather sad, given that with practically any other application (Line, WeChat, GTalk, Skype) you can talk via phone, tablet or PC, and with WhatsApp I have to message my friends with a tiny phone screen while my wonderful desktop keyboard and dual monitors sit there laughing at me.
The apps developed by Moxie Marlinspike also seem good to me, I've used RedPhone and it's pretty nice. The texting app sends SMS, though, it doesn't go through the Internet, so it might not be what you're looking for.
Silent Circle's mail service was shut in the aftermath of the Lavabit shutdown. Why shouldn't that happen to the messaging service? What's the difference?
Unfortunately, Threema is not FOSS either.
if jabber worked, we wouldn't be talking about whatsapp/hemlis/threema.