Ryzom is an online role-playing game. If you happen to be playing it, using the in-game browser is a significant risk. When you do that, there is a chance that somebody will run their Lua code in your client and bad things will happen.
People searching for a Google Chrome ad blocking extension have to choose from dozens of similarly named extensions. Only few of these are legitimate, most are forks of open source ad blockers trying to attract users with misleading extension names and descriptions. What are these up to? Thanks to Andrey Meshkov we now know what many people already suspected: these extensions are malicious. He found obfuscated code hidden carefully within a manipulated jQuery library that accepted commands from a remote server.
After my article on the browser sync mechanisms I spent some time figuring out how Firefox Accounts work. The setup turned out remarkably complex, with many different server types communicating with each other even for the most basic tasks. While this kind of overspecialization probably should be expected given the scale at which this service operates, the number of different authentication methods is surprising and the official documentation only tells a part of the story while already being fairly complex. I’ll try to show the entire picture here, in case somebody else needs to piece it all together.
A few days ago I wrote about insufficient protection of locally saved passwords in Firefox. As some readers correctly noted however, somebody gaining physical access to your device isn’t the biggest risk out there. All the more reason to take a look at how browser vendors protect your passwords when they upload them to the cloud. Both Chrome and Firefox provide a sync service that can upload not just all the stored passwords, but also your cookies and browsing history which are almost as sensitive. Is it a good idea to use that service?
TL;DR: The answer is currently “no,” both services have weaknesses in their protection. Some of these weaknesses are worse than others however.
There is a weakness common to any software letting you protect a piece of data with a password: how does that password translate into an encryption key? If that conversion is a fast one, then you better don’t expect the encryption to hold. Somebody who gets hold of that encrypted data will try to guess the password you used to protect it. And modern hardware is very good at validating guesses.
Case in question: Firefox and Thunderbird password manager. It is common knowledge that storing passwords there without defining a master password is equivalent to storing them in plain text. While they will still be encrypted in logins.json file, the encryption key is stored in key3.db file without any protection whatsoever. On the other hand, it is commonly believed that with a master password your data is safe. Quite remarkably, I haven’t seen any articles stating the opposite.
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).
Once upon a time, Google dared to experiment with HTTPS encryption for their search instead of allowing all search data to go unencrypted through the wire. For this experiment, they created a new subdomain: encrypted.google.com was the address where your could get some extra privacy. What some people apparently didn’t notice: the experiment was successful, and Google rolled out HTTPS encryption to all of their domains. I don’t know why encrypted.google.com is still around, but there doesn’t seem to be anything special about it any more. Which doesn’t stop some people from imagining that there is.
This server was overdue for a migration to new hardware, and I used this opportunity to make its setup reproducible by basing it on Docker containers. This allowed me to test things locally, setting everything up on the real server was only a matter of one hour then. Some issues I didn’t recognize locally however, most importantly Docker’s weird IPv6 support. Everything worked just fine when the server was accessed via IPv4, accessing it via an IPv6 address caused connections to hang however. I hit this issue with Docker 1.13.1 originally, updating to Docker 17.12 didn’t change anything. Figuring this out took me quite a while, so I want to sum up my findings here.