The major change in PfP: Pain-free Passwords 2.1.0 is the new sync functionality. Given that this password manager is explicitly not supposed to rely on any server, how does this work? I chose to use existing cloud storage like Dropbox or Google Drive for this, PfP will upload its encrypted backup file there.
This would be pretty trivial, but sync functionality is also supposed to sync records if data is modified by multiple clients concurrently. Not just that, sync has to work even when passwords are locked, meaning: without the possibility to decrypt data. The latter is addressed by uploading local data without any modifications. Records are encrypted in the same way both locally and remotely, so decrypting them is unnecessary.
With the important 2.0 milestone I decided to give my Easy Passwords project a more meaningful name. So now it is called PfP: Pain-free Passwords and even has its own website. And that’s the only thing most people will notice, because the most important changes in this release are well-hidden: the crypto powering the extension got an important upgrade. First of all, the PBKDF2 algorithm for generating passwords was dumped in favor of scrypt which is more resistant to brute-force attacks. Also, all metadata written by PfP as well as backups are encrypted now, so that they won’t even leak information about the websites used. Both changes required much consideration and took a while to implement, but now I am way more confident about the crypto than I was back when Easy Passwords 1.0 was released. Finally, there is now an online version compiled from the same source code as the extensions and having mostly the same functionality (yes, usability isn’t really great yet, the user interface wasn’t meant for this use case).
Now that the hard stuff is out of the way, what’s next? The plan for the next release is publishing PfP for Microsoft Edge (it’s working already but I need to figure out the packaging), adding sync functionality (all encrypted just like the backups, so that in theory any service where you can upload files could be used) and importing backups created with a different master password (important as a migration path when you change your master password). After that I want to look into creating an Android client as well as a Node-based command line interface. These new clients had to be pushed back because they are most useful with sync functionality available.
I’ve finally released Easy Passwords as a Web Extension (not yet through AMO review at the time of writing), so that it can continue working after Firefox 57. To be precise, this is an intermediate step, a hybrid extension meant to migrate data out of the Add-on SDK into the Web Extension part. But all the functionality is in the Web Extension part already, and the data migration part is tiny. Why did it take me so long? After all, Easy Passwords was created when Mozilla’s Web Extensions plan was already announced. So I was designing the extension with Web Extensions in mind, which is why it could be converted without any functionality changes now. Also, Easy Passwords has been available for Chrome for a while already.
The trouble was mostly the immaturity of the Web Extensions platform, which is why I chose to base the extension on the Add-on SDK initially (hey, Mozilla used to promise continued support for the Add-on SDK, so it looked like the best choice back then). Even now I had to fight a bunch of bugs before things were working as expected. Writing to clipboard is weird enough in Chrome, but in Firefox there is also a bug preventing you from doing so in the background page. Checking whether one of the extension’s own pages is open? Expect this to fail, fixed only very recently. Presenting the user with a file download dialog? Not without hacks. And then there are some strange keyboard focus issues that I didn’t even file a bug for yet.
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.
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:
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.
When I started writing my very own password generation extension I didn’t know much about the security aspects. In theory, any hash function should do in order to derive the password because hash functions cannot be reversed, right? Then I started reading and discovered that one is supposed to use PBKDF2. And not just that, you had to use a large number of iterations. But why?