Can I trust my Chrome Sync and Firefox passwords?

Recently I wrote about insufficient protection of locally saved passwords in Firefox . As some readers have correctly 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 download not only the saved passwords, but also cookies, and the history of page views. How safe is this service?
 
 
TL; DR: currently the answer is "no". Both services have weaknesses in defense. However, some of these shortcomings are worse than others.
 
optional . In the settings there is no warning like "Hey, do not 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 is opening access to passwords through the web page . 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 the password is set? It will be used to obtain (among other things) the encryption key - and your data is encrypted with this key. Of course, here there is a big question: if someone gets your encrypted data from the server, how much password is protected from bruteforce? It turns out that Chrome uses PBKDF2-HMAC-SHA1 with 1003 iterations.
 
 
What does this mean? Here I again for reference will give the figures from this article : taking into account 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 leaks of websites, are reduced in less than 8 minutes. What about a strong password with 40bit entropy, which is these specialists are consider the average password for people? Probably, experts overestimate the ability of people to choose good passwords, but in about two days this password will be matched.
 
 
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, you can attack at once at all. Thus, in four days a password will be chosen for any account, where a password with entropy up to 40 bits is used. Keep in mind that Google itself has enough hardware 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 $ ?000 on equipment.
 
 
I registered this bug in the tracker with No. 820976 , keep for updates.
 
 
Note. Special thanks to Chrome for its creativity in wasting CPU resources. This function runs PBKDF2 four times, although one pass is enough. The first launch gets the salt from the host name and the user name (in case of synchronization, Chrome is constants). It's pretty pointless: salt should not be a secret, it just needs to be unique. So combining values ​​or running SHA-256 on them gives the same effect. The next three starts generate three different keys from identical input data, using a different number of iterations. One call to PBKDF2 with data generation for all three keys would clearly be more efficient.
 
 

Synchronization Firefox


 
Synchronization Firefox uses well documented Firefox Accounts protocol. to set encryption keys. Although the various parameters and the operations performed there can be confusing, but it seems that this is a well thought out approach. If someone gets access to the data stored on the server, they will have to deal with keys based on scrypt . Scanning scrypt on specialized hardware is much more complicated than PBKDF? 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, 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 the transfer to the server, it can be relatively easy to find a password. In this case, one Nvidia GTX 1080 will check 1.2 million hashes per second. Although for each account you will have to start the operation anew, but checking 1.5 billion known passwords takes 20 minutes. And the password with 40-bit entropy is predicted on average over five days. Depending on the content of the account, such a waste of resources can pay off.
 
 
The most interesting: Mozilla paid for the security audit of Firefox Accounts, and this audit indicated the generation of the key on the client side as a key drawback of . Thus, Mozilla knows about the problem for at least 18 months, and 8 months ago even published this information. What's the matter? Apparently, the problem was not considered too important. Perhaps this is partly due to the fact that the auditor incorrectly estimated 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 get 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 server api.accounts.firefox.com 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) will decide to look at someone's data. What if American authorities knock on Mozilla?
 
 
I originally fixed this bug as 1444866 . Now it is marked as a duplicate of the bug 1320222 - I could not find it, because it was marked as "security sensitive", although it does not contain any new information.
+ 0 -

Add comment