Author Archives: Tobias Boelter

Where to store your auth token? Cookie or JS? Both!

In the security community, there is a contention on whether an auth token (think OAuth access_token, JSESSIONID, ...) should be stored inside a cookie or if should live within javascript, so e.g. a variable in a single page application, local storage or session storage, etc.

If it is stored in javascript, all requests to resources that require auth have to be made from JS, so it is usually difficult to retrofit an application that was written for cookie-based auth to have it store the auth token in JS.

That being said, for new applications, the developers have to make this decision. Which one is more secure? It is often said that cookies are safer against XSS (with the HttpOnly flag set), but using cookies makes your app more vulnerable to CSRF. Tokens within JS, on the other hand, are easier to exfiltrate through XSS but CSRF therefore becomes much less of a problem.

But why not just combine the two approaches to get the best of both worlds? The web application can split the auth_token into two by doing: 

r := random_bytes()
share1 := auth_token XOR r
share2 := r

share1 can then be set as a cookie and share2 as a JS variable. The web frontend then needs to always provide both shares to the backend to authorize a request.

Instead of XOR, other cryptographic operations are possible, but XOR is especially performant and should be easily available in every programming environment.

Feelings

The WhatsApp vulnerability debate got quite heated up and polarized people. I wish I could have had this debate with the Facebook Security Team in Whitehat Report #1008534892515816. In private, without the public listening and judging our opinions, agreeing on a solution and giving a joint statement at the end. Continue reading →

A response to the denials from moxie and WhatsApp

This post is a direct response to moxie's post, hence the original title "There is a WhatsApp Backdoor", which I have changed now because I find the "Backdoor vs. Vulnerability" discussion uninteresting.

You can argue if we are looking at a vulnerability, so something that is in there by error, or a backdoor, i.e. something that is in there deliberately. But this discussion is not very interesting.

Facebook and moxie do not deny that there is a vulnerability that can be used to 'wiretap' targeted conversations, for example by governments with access to WhatsApp servers. For details on the vulnerability, see my initial blog post, some slides, or my video. In the video, you can also see that the vulnerability can not be avoided by verifying fingerprints or checking a checkbox in the WhatsApp settings.

The UX 'downgrade' we are talking about

Signal does not have this vulnerability, but WhatsApp has it. So how are they different? How more difficult is Signal to use?

Imagine you dump your phone into the ocean and only a month later you get a new phone. Then during this one month time period, some friends might've sent you messages. In WhatsApp, your friends phones are being instructed to automatically re-encrypt and retransmit. But they don't know if they are sending the messages indeed to you or the government. Then, and only if your friends specifically asked WhatsApp to do so, they will see a warning that there could've been something shady going on. Signal on the other hand will tell your friends something like "there might've been something shady going on. Do you want to resend your message?".

First: How often do those situations occur? I'd say not so often, WhatsApp says "millions of messages", which is actually not that much considering they are sending like 42 billion (with a b) messages per day through their servers.

Second: Is it really that much to ask for from the users?

Even with the "give me additional security" setting, WhatsApp retransmits messages

So there is this setting in WhatsApp "Show security features". It basically tells WhatsApp "Hey, I'm especially concerned about my privacy. I know what I am doing. Please give me the best privacy possible". But even with this setting enabled, WhatsApp will automatically re-encrypt and retransmit messages, leaving the sender vulnerable.

Moxie tries to explain why this choice has been made:

The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully.

This claim is false. Those "blocking" clients could instead retransmit a message of the same length that just contains garbage, i.e. instead of "Login with the password d98y289whcma0", they'd send "0000000000000000000000000000000000000" and this message would just not be displayed by the receiver's phone. By the guarantees of encryption, those two messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible.

Only one message?

There have been claims that only one single message is exposed before the sender notices that something shady might be going on. For technical reasons, only the case with one message can be demonstrated, but there is reason to believe the attack can be extended to a longer conversation. The Signal protocol allows "lost or out-of-order messages". Therefore it should be possible for the WhatsApp server to block all "message has been received" notifications for a long conversation while it still correctly forwards the actual text messages. The "receipt" notifications, if encrypted at all, can be distinguished from the normal text messages because they are the ones sent directly after the receiver receives the message.

The users would then only get displayed one tick for all their messages, but won't bother because it is working. After days, weeks or maybe even month, the described attack can then be launched in order to get a copy of the whole transaction history since that point in time.

File transfers and voice calls affected as well

Not only messages, but also voice calls and file transfers can be intercepted with this vulnerability.

moxie, I do respect all the work you've done to promote widespread encryption. But regarding this topic you're wrong.

Facebook, please just fix this. Here is a personal suggestion what to do.

 

What is Facebook going to do? A suggestion.

The WhatsApp retransmission vulnerability has gained a lot of public attention today led by an article published by The Guardian. So what can Facebook (the owner of WhatsApp) do now? I think chances are pretty low that they come forward and say "yep, this is a backdoor, here is a copy of the NSL". Will they say "yep, this is a critical vulnerability, but it took us 8 month and 20 newspaper articles to fix it, because ... crrzzz ... crzzz ... the connection is really bad ... can you hear me? ... duut duut duut"? Unlikely. So the only option for them I can think of is to say "It's not a bug! It's a feature! It increases usability!".

Of course this is not a good argument. As Eike Kühl pretty well describes, this functionality only increases usability in a rare corner case: When you dump your phone in the ocean and you need a month to get a new one. Then everyone who has sent you a message during this period will not need to press an additional "OK" button.

I don't know about you, but the door of my apartment has a lock and I need a key to open it. Sometimes the inevitable happens and I forget my key inside my apartment and I only realize this after closing the door. Then I need to call and pay someone to come, check my ID, and open the door. This is very inconvenient. It would be much more convenient if the door stayed unlocked day and night. But am I willing to trade the worse security for the convenience? No! Just like in the case of automatic WhatsApp message re-encryption.

So here is my recommendation to you, Facebook: Say that this was intended as a feature, but acknowledge that you have made the wrong security trade-off. You can keep your face and fix the vulnerability. To restore trust into your messaging platform you should release the source code of the clients. Your business asset is not the source code of the messenger app, it is your massive user-base. The source code of your highly scalable server infrastructure is a true business asset but that part you don't have to disclose. For the client software there are anyways enough open-source solutions available that any competitor could just pick up.

After you have done that, you should consider working towards reproducible builds. This will again boost trust in your platform. And finally, if you could avoid storing all the metadata about us, like Signal claims, that would be even better!

WhatsApp vulnerability: Bug or Backdoor?

In April last year I reported on a vulnerability in WhatsApp. It now gained public attention as it has not been fixed yet. One question now is: Is it a bug or a backdoor? In other words: Is this flaw put deliberately into the WhatsApp messenger to allow them or the government to look at targeted messages? Or is the flaw introduced through a simple programmer error? Or is it even a useful feature?
If someone would demand WhatsApp to implement a backdoor, you might expect them to implement something more obvious. Like responding with the history of all conversations when triggered to so do with a certain secret message. Furthermore, this flaw can be explained as a programming bug. Just a missed "if" statement for one of the corner cases. It is a type of flaw that is not necessarily introduced by malice, just like many other critical vulnerabilities in important products that are reported daily.
But Facebook showed no interest in fixing the flaw since I reported it to them in April 2016. So maybe it was a bug first, but when discovered it got started being used as a backdoor?
WhatsApp has stated recently that this is not a bug, it is a feature! Because now senders don't have to press an extra "OK" button in the rare case they sent a message, the receiver is offline and has a new phone when coming back online. That's not a very good argument! And if "Privacy and Security is in [WhatsApp's] DNA", they should have fixed the flaw immediately after I reported it in April 2016.

Applying for Software Engineering Jobs in the U.S.

I am in the process of applying to some tech companies for the next summer (contact me if you have an open position hehe). Here are some things I experienced and also some tips for the ones also applying.

From Germany I was used to a very easy-going process. Companies highly valued credentials (degrees, courses taken, references, ...) for the technical skills. Interviews were then focused on soft skills and assessing at which team/project I could apply my strength best. Interviews were always directly with a representative from the team/group I was applying to. Soft skills would be assessed through team exercises (not technical) in so-called "assessment centers", role plays, experience questions (like"can you tell me about a situation where it was difficult to work with other people?") and other questions like "what do you think is important for good time management?". Then, for the rest of the interview they would explain different projects they are hiring for and try to see how I could fit into them. The whole process would usually only involve an initial phone call to discuss logistics and then one on-site interview. Most German companies value etiquette highly. Your writing better be flawless and the cover letter is probably the most important part of the application. It is really important to make a good point about why this company excites you.

My experience in the U.S. is very different. The initial contact is very focused on the "résumé". Recruiters at job fairs will sometimes just ask you for your résumé and that's it. Students will sometimes come to tech talks just to give their résumé to the recruiter and won't even stay for the talk. Also there are companies whose entire application process just consists of uploading a résumé. So are applications in the US very credential based? I can't say either, because most companies haven't even asked me for transcripts or reference letters. And many emphasize that they recruit people with all sorts of education paths. Weird. Instead, I would say that recruiting is less credential based than in Germany, because the U.S. companies all want to assess technical skills themselves through a series of technical phone interviews. And only if you pass through them you get an onsite interview. I honestly have my doubts on how good this process is as the sample size the company gets from two or three 45 minute technical phone interviews is rather small. Further, at some companies the interviews are with random software engineers in the company, who don't know about you, and have little incentive to make a good phone interview. But maybe degrees from U.S. universities don't say much, many applicants went through a different education or many applicants are from foreign countries with uncertainty about the significance of their degrees.

Anyways. To be successful, one needs to specifically prepare for this kind of interview. I recommend skimming the book Cracking the Coding Interview to get gist of why companies think they do these interviews, what they are looking for, what to expect, as well as some general strategies for answering questions. The book also contains sufficient review material to quickly freshen up your basic programming skills if needed. Then there is also a section of typical interview problems. But there are websites that provide the same and also let you write and test the code on the website directly. I can recommend CodeLab and LeetCode. Topcoder is another site that many recommend, but it's much more blown up. The book, on the other hand has very good solutions to the problems and also a good system of giving you hints if you're stuck. But don't be fooled. The interview questions I was asked in the actual interviews were sometimes much tougher than the ones in the book or online.

Another recommendation I have is Triplebyte (a Y Combinator company). The concept is that you do the first round of technical interviews with them (first online and then over the phone). If you are successful, you can then directly go to the onsite interviews of their partners. And they have a lot of very interesting partner companies. They save you a lot of stress. Otherwise you would have pretty much the same interview round with all the companies you apply for. That's not only cost for you, it's also cost for the companies. So by saving this cost, Triplebyte is able to invest more into optimizing their interview process. They also have a nice philosophy: Very data-driven, they don't look at credentials at all, and they focus on the applicants strength instead of weaknesses. So I highly recommend checking them out if you are applying for interviews/jobs in the space: Triplebyte.

 

US Credit Cards Overview

This was written in 2016. If you read this in >= 2018 there is a good chance this is outdated.

Usually I don't post commercial stuff. But I think other people moving to the US might find this helpful. I did a quite comprehensive survey of the consumer credit card market and want to share my findings. If you live here for a year or longer you need to get a US credit card. Often enough this is the only form of payment accepted and international credit cards often enough fail for random reasons. I'm going to assume that you do not want the credit card for the credit, and that you will pay your total balance all at once and on time. If not, you should look into other offers. If not explicitly said, cards mentioned here do not come with annual membership fees.

Using the best offers I found, I'll get roughly $1000 cash back per year with the spending profile of a regular graduate student, so it is worth thinking for a few hours about a good strategy. Continue reading →

My Take on The Internet of Things

Right now we are on the way to create a next generation of the Internet, the Internet of Things. The Internet of Things (IoT) will have a huge impact on many aspects of our lives. It will change the way we interact, the way we live, and the way we think. Remember the years where we had big debates on how the electronic address book in our phones will change our ability to remember things? Well, in the next years not only our phones will become smarter, every_thing will become smarter. Ordinary “things” like our cars, our TVs, our refrigerators, watches, light bulbs, but also industrial assembly-line robots become more and more connected and “smarter”. In an exemplary scenario this means that the bulk of data produces by an ensemble of sensors in our cars can be analyzed in the cloud to find subtle defects or inefficiencies and this information can directly be communicated to the robots in the assembly line to improve the production process. Next to mobility and industry, the health sector, urban living, retail and energy are just a few other sectors where the IoT will have a huge impact.

Trying to predict the future and imagine how the IoT will exactly change things and identify upcoming challenges on this path, I want to first distill the game-changing factors related to IoT. I will then relate those to the Security and Privacy issues arising and present a (not even) half-baked solution.

In IoT there is the I and the T. Let’s look at the T, the things, first. The number of things with general purpose chips and rich connectivity will skyrocket in the next decade. While a traffic light today might only hold a small electronic circuit of a few gates, it will soon be equipped with a whole general purpose microprocessor and in addition to the signal wire which connects it with the other lights at the intersection, it will have a WiFi chip or an Ethernet interface. Putting more hardware into things and giving them more capabilities is simply a ramification of always decreasing cost of this hardware. Continue reading →

Security: Status Quo

On Tuesday, June 21, 2016, the Commission on Enhancing National Cybersecurity #WHCyberComm met in Berkeley to get input from Industry and others. The main goal of the commission is to produce a “transition” memo to the next president to implement important policy changes within the first 100 days of the new administration, which is usually a time window where dramatic moves are made. The industry witnesses highly valued their chance to bring across their views and influence policy decisions to their benefit which made it an interesting event to watch. In this blog post I try to summarize the most important points that were made during the day. Continue reading →

WhatsApp Retransmission Vulnerability

Last week I already tweeted

WhatsApp message not delivered. Contact announces new public key. Auto retransmits messages encrypted under new key. head -> table.

That explains this simple bug in the latest WhatsApp version, which now promises beautiful end-to-end encryption, very good. But for my not so nerdy friends I want to provide some more explanation. I'm not following the usual responsible disclosure procedure here as WhatsApp users are not less secure than when they did not have end-to-end encryption at all. A white-hat report to facebook (#1008534892515816) has been submitted.

Setting: Three phones. Phone A is Alice's phone. Phone B is Bob's phone. Phone C is the attacker's phone. Continue reading →