I recently wrote about the lack of protection of locally stored passwords in Firefox . As some readers rightly pointed out, an attacker with physical access to your device is not the main threat. So let's take a look at how browser developers protect your passwords when they are transferred to the cloud. Both Chrome and Firefox provide a synchronization service that can load not only stored passwords, but also cookies and browsing history. How safe is this service?

TL; DR: currently the answer is "no." Both services have security weaknesses. However, some of these shortcomings are worse than others.

Chrome sync

I'll start with Chrome sync, where the answer is more predictable. In the end, several things indicate that this service is designed more for convenience than for privacy. For example, a password to protect your data from Google is optional . In the settings there is no warning like "Hey, do you care that we can look into your data? Better set the password. ” Instead, the user must take the initiative. Another sign is that Google allows access to passwords through a webpage . Probably the idea is that you can open this web page from someone else's computer, for example, from an Internet cafe. A good idea? Hardly.

In any case, what happens after setting the password? It will be used to obtain (among other things) the encryption key - and your data is encrypted with this key. Of course, the big question here is: if someone gets your encrypted data from the server, how is the password protected from brute force? It turns out that Chrome uses PBKDF2-HMAC-SHA1 with 1003 iterations.
')
What does this mean? Here again, for reference, I will cite the figures from this article : with these iterations, one Nvidia GTX 1080 graphics card can calculate 3.2 million hashes of PBKDF2-HMAC-SHA1 per second. This is 3.2 million guessed passwords per second. That is, 1.5 billion passwords known from various website leaks are counted in less than 8 minutes. What about a strong password with a 40-bit entropy, which these experts consider the average password of people? Probably, experts overestimate the ability of people to choose good passwords, but in about two days this password will be picked up.

In fact, the situation is even worse. The salt that Chrome uses to get the key is a constant. This means that the same password for different Chrome users corresponds to the same encryption keys. In turn, this means that if there is a large amount of data from different users, it is possible to carry out an attack on everyone at once. Thus, in four days, a password will be selected for any account where a password with entropy up to 40 bits is used. Keep in mind that Google itself has enough equipment to do this work in a few minutes, if not seconds. I'm talking about those intruders who do not want to spend more than $ 1,000 on equipment.

I registered this bug in the tracker with the number 820976 , stay tuned.

Note. Special thanks to Chrome for their creativity in wasting CPU resources. This function drives PBKDF2 four times, although one pass is sufficient. The first run gets the salt on behalf of the host and username (in the case of synchronization, Chrome is a constant). This is pretty pointless: salt should not be a secret, it just has to be unique. So combining values ​​or running SHA-256 on them has the same effect. The following three runs generate three different keys from identical input data using a different number of iterations. One PBKDF2 call with data generation for all three keys would obviously be more efficient.

Firefox sync

Firefox sync uses the well-documented Firefox Accounts protocol to set encryption keys. Although the various parameters and the operations performed there may be confusing, it seems that this is a well thought out approach. If someone gains access to the data stored on the server, they will have to deal with scrypt- based keys. Busting scrypt on specialized equipment is much more complicated than PBKDF2, if only because each scrypt call requires 64 MB of memory - if you take into account the parameters that Mozilla uses.

However, there is a significant drawback: scrypt runs on the Firefox Accounts server, and not on the client side. On the client side, this protocol uses PBKDF2-HMAC-SHA256 with only 1000 iterations. And although the received password hash is not stored on the server, but if someone intercepts it during transmission to the server, it can relatively easily find the password. In this case, one Nvidia GTX 1080 video card will check 1.2 million hashes per second. Although each account will have to restart the operation, checking 1.5 billion known passwords will take 20 minutes. And a password with 40-bit entropy will guess on average in five days. Depending on the content of the account, such a waste of resources can pay off.

Highlight: Mozilla paid for the Firefox Accounts security audit, and this audit indicated key generation on the client side as a key flaw . Thus, Mozilla knows about the problem for at least 18 months, and even published this information 8 months ago. What's the matter? Apparently, the problem was not considered too important. Perhaps this is partly due to the fact that the auditor incorrectly assessed the risk:

The attack involves a very strong attacker who is able to bypass TLS.

Of course, one of the possible ways to conduct an attack would be to obtain a valid certificate for api.accounts.firefox.com and redirect traffic to your own server. But it is more likely that the security of the api.accounts.firefox.com server itself will be compromised. Even if the server is not hacked, there is always a chance that a Mozilla or Amazon employee (the server is hosted on AWS) decides to look at someone's data. What if the American authorities knock on Mozilla?

I originally reported this bug as 1444866 . Now it is marked as a duplicate of bug 1320222 - I could not find it, because it was marked as “important in terms of security” (security sensitive), although it does not contain any new information.