This announcement by the Princeton University is making its rounds in the media right now. What the media seems to be most interested in is their promise of ad blocking that websites cannot possibly detect, because the website can only access a fake copy of the page structures where all ads appear to be visible. The browser on the other hand would work with the real page structures where ads are hidden. This isn’t something the Princeton researchers implemented yet, but they could have, right?
First of all, please note how I am saying “hidden” rather than “blocked” here — in order to fake the presence of ads on the page you have to allow the ads to download. This means that this approach won’t protect you against any privacy or security threats. But it might potentially protect your eyes and your brain without letting the websites detect ad blocker usage.
As I mentioned previously, an efficient PBKDF2 implementation is absolutely essential for Easy Passwords in order to generate passwords securely. So when I looked into Microsoft Edge and discovered that it chose to implement WebCrypto API but not the PBKDF2 algorithm this was quite a show-stopper. I still decided to investigate the alternatives, out of interest.
First of all I realized that Edge’s implementation of the WebCrypto API provides the HMAC algorithm which is a basic building block for PBKDF2. With PBKDF2 being a relatively simple algorithm on top of HMAC-SHA1, why not try to implement it this way? And so I implemented a fallback that would use HMAC if PBKDF2 wasn’t supported natively. It worked but there was a “tiny” drawback: generating a single password took 15 seconds on Edge, with Firefox not being significantly faster either.
My latest news validation adventure started because my wife overheard a show on Russian TV explaining the “real” reasons behind the Syrian civil war. The argument appeared to be balanced by explaining how various foreign forces have a hidden agenda in the conflict — including Russia which needs to prevent the Quatar-Turkey pipeline from happening. And what’s in for US? According to that show, vast amounts of oil were discovered in Syria and the US were looking for ways to exploit those. Such an easy and simple explanation for a very complex conflict seemed suspicious and so I decided to look into it.
First of all, I wasn’t aware of Syria being one of the top oil producing countries. Wikipedia appears to confirm that by stating that Syrian oil production has been on decline for a while already and that the reserves might be depleted soon. I searched a bit and immediately hit this German-language article on NeoPresse.com claiming that huge oil fields were discovered in Syria shortly before the war — exactly the story that my wife heard. And the source? RF-SMI, a Russian-language news site. And that seems to be the original source already, it doesn’t go any further. All other articles appear to have taken their information from either the NeoPresse or RF-SMI article. Funny enough, even some Russian-language sites appear to have picked up the news from NeoPresse and translated it back to Russian.
With Easy Passwords I develop a product which could be considered a Last Pass competitor. In this particular case however, my interest was sparked by the reports of two Last Pass security vulnerabilities (1, 2) which were published recently. It’s a fascinating case study given that Last Pass is considered security software and as such should be hardened against attacks.
I decided to dig into Last Pass 4.1.21 (latest version for Firefox at that point) in order to see what their developer team did wrong. The reported issues sounded like there might be structural problems behind them. The first surprise was the way Last Pass is made available to users however: on Addons.Mozilla.Org you only get the outdated Last Pass 3 as the stable version, the current Last Pass 4 is offered on the development channel and Last Pass actively encourages users to switch to the development channel.
My starting point were already reported vulnerabilities and the approach that Last Pass developers took in order to address those. In the process I discovered two similar vulnerabilities and a third one which had even more disastrous consequences. All issues have been reported to Last Pass and resolved as of Last Pass 4.1.26.
My colleague Dave Barker is pushing me towards making Easy Passwords a full-featured LastPass alternative. Given the LastPass security vulnerabilities that were publishedrecently and the ones I am about to publish myself soon I cannot really blame him. Getting there will take a while but we’ve reached an important milestone on the way: with Easy Passwords 1.1.0 user names will now be filled in automatically as well, so for most login forms you won’t need to type anything at all any more. Implementing this feature in a user-friendly way was more complicated than it sounds, if you are interested you can see the iteration process we went through in the corresponding issue.
Now that this is out of the way the next steps are:
As extension formats go, Apple clearly chose the most obscure and least documented one for their Safari browser. It’s based on the XAR (eXtensible ARchiver) format which is a dead project with barely existing and outdated format documentation (note how it suggests setting XAR_HEADER_VERSION to zero even though current header version is one). But Apple went further and added signing support to the format without documenting it. Why bother if everybody can use Safari to create an extension package? And so for a long time your best choice to automate the build process was a complicated list of instructions relying on a patched version of the xar command line tool. A year ago somebody apparently added a much more convenient xar-js library to the list but I didn’t find out until I started writing this blog post.
Yesterday I was transitioning our build process from M2Crypto which has neither Python 3 support nor useful documentation to PyCrypto which has both. While at it, I had to spend an awful lot of time reimplementing step 3 of that complicated list of instructions, namely creating a valid signature. It wasn’t working no matter what I tried, and I ended up understanding the format a lot better than I ever wished for. As it turned out, this step was relying on a broken RSA signing implementation as offered by the deprecated openssl rsautl command and M2Crypto, but which PyCrypto chose not to implement for obvious reasons. I solved the problem, but in the process I realized that the format is simpler than the unsupported command line tool with its quirks and bugs. And so I created our own XAR generator which no longer relied on that command line tool (not quite general-purpose code unfortunately).
As Mozilla’s Web Extensions project is getting closer towards being usable, quite a few people seem to expect some variant of Chrome’s permission prompt to be implemented in Firefox. So instead of just asking you whether you want to trust an add-on Firefox should list exactly what kind of permissions an add-on needs. So users will be able to make an informed decision and Mozilla will be able to skip the review for add-ons that don’t request any “dangerous” permissions. What could possibly be wrong with that?
In fact, lots of things. People seem to think that Chrome’s permission prompt is working well, because… well, it’s Google and they tend to do things right? However, having dealt with the effects of this prompt for several years I’m fairly certain that it doesn’t have the desired effect. In fact, the issues are so severe that I consider it security theater. Here is why.
My Easy Passwords extension is quickly climbing up in popularity, right now it already ranks 9th in my list of password generators (yay!). In other words, it already has 80 users (well, that was anticlimatic). At least, looking at this list I realized that I missed one threat scenario in my security analysis of these extensions, and that I probably rated UniquePasswordBuilder too high.
The problem is that somebody could get hold of a significant number of passwords, either because they are hosting a popular service or because a popular service leaked all their passwords. Now they don’t know of course which of the passwords have been generated with a password generator. However, they don’t need to: they just take a list of most popular passwords. Then they try using each password as a master password and derive a site-specific password for the service in question. Look it up in the database, has this password been ever used? If there is a match — great, now they know who is using a password generator and what their master password is.
Easy Passwords is based on the Add-on SDK and runs in Firefox. However, people need access to their passwords in all kinds of environments, so I created an online version of the password generator. The next step was porting Easy Passwords to Chrome and Opera. And while at it, I wanted to see whether that port will work in Firefox via Web Extensions. After all, eventually the switch to Web Extensions will have to be done.
