We received some great feedback on the original article about attacking master passwords of several popular password managers. In one discussion, our benchmark numbers for 1Password were questioned. We had no choice but to re-run the benchmarks and publish an updated chart along with some technical details and explanations. We bring our apologies to AgileBits, the developers of 1Password, for letting the wrong number creep in to our benchmark. Can we still break into 1Password by attacking the master password? Please bear with us for up-to-date information and detailed technical discussion.

We must make one thing extremely clear: this time we did not “hack” anything. We are using good old brute force, enhanced with GPU acceleration, to attack the user’s plain-text master password protecting password managers’ encrypted databases. The four password managers were and still remain secure providing that the user opts for a strong master password. If a truly secure master password is used, it would not be possible to break it within reasonable timeframe.

The Benchmark

Attacks assisted with a top of the line GPU (NVIDIA GeForce GTX 1080 is what we used) return measurable performance. The purpose of our article was not comparing password managers to each other or Microsoft Office encryption. Instead, we wanted to give our forensic customers an idea, a rough estimate of time and resources it would take them to break passwords of certain length.

First, let’s have a look at the wrong scores from the original article:

https://blog.elcomsoft.com/wp-content/uploads/2017/08/b01-768×378.png

Below is the new chart with updated password recovery speeds:

So home did we come to the numbers in the first benchmark, and why do they differ from what you see in the second benchmark? The reason lies in our development pipeline. Elcomsoft Distributed Password Recovery supports several hundred data formats, some of which can be protected with adjustable parameters. We started developing support for password manager apps a long time ago. At that time, we saved sample databases for development and testing purposes. Long story short; while we did in fact implement support for the latest versions of all four password managers, our testers still used sample databases from long ago.

So which versions of the password manager apps did we use for our original benchmarks, and which ones do we use now for the new score?

• KeePass 2.36: we measured the same score (120K passwords/s); see note below
• LastPass (Windows Chrome plug-in) 4.1.61; we came to the same score (about 45K p/s). This time, however, we kept attention on the number of hash iterations, which was 5000. Do note that the user can bump this number, slowing down the recovery speed significantly. Rest assured we can attack passwords hashed with any number of iterations, yet the speed of the attack will change proportionally.
• Dashlane 4.8: no surprises, same score (about 130K p/s)

A Word on KeePass

Since KeePass is an open source project, it can be customized. Check out these contributed/unofficial KeePass ports: http://keepass.info/download.html

We received the following comment on KeePass from one of our readers:

It is also worth noting that the number of transformation rounds in KeePass can easily be customized (same for KeePassXC and KeePassX). There is even an option to automatically calibrate a number of rounds which require about 1 second per password attempt on your current machine.

Also the new KDBX4 format wasn’t mentioned at all, which uses Argon2 as key derivation function. Argon2 was specifically designed to make bruteforce attempts really hard and memory consuming (even on GPUs).

Even the official version allows customizing the number of hash iterations. The default value is 6000 iterations on desktops; mobile apps can use the same or lower numbers. In our benchmarks, we used the default value.

In addition to master password, KeePass allows specifying an optional “Key File”, which can be just about any file on the user’s device. This file is then used as an additional extra-long and ultra-secure password; however, if that file is lost or if its content is altered in any way, access to encrypted passwords will be lost forever.

Starting with KeePass 2.35, the database may be stored in the new KBDX4 format. In order to use the new format, the user must manually specify options for database file encryption and key derivation function.

http://i.imgur.com/wVpmsA9.png

Mobile versions of KeePass as well as unofficial ports are mostly still using the v2 database format (that’s the one we’ve tested). We don’t currently support the new KBDX4 format, but we are ready to add it on request from our registered users. Having said that, we expect seeing significantly lower recovery speeds for the new format since the encryption algorithm is decidedly not GPU friendly.

1Password

The most serious issue we had was with 1Password. The updated score is an order of magnitude slower compared to one we originally measured. Jeffrey Goldberg from AgileBits contacted us and pointed out the problem.

Hello, I am Jeffrey Goldberg from AgileBits, the makers of 1Password.

I am perplexed by your results. In the latest version of 1Password, we use 100,000 rounds of PBKDF2-HMAC-SHA256 in our Key Derivation Function (KDF). Our immediately previous data format (OPVault) used at least (calibrated) 40,000 rounds of PBKDF2-HMAC-SHA512.

Only early versions of our long deprecated Agile Keychain Format, which may have used as few as 10,000 rounds of PBKDF2-HMAC-SHA1 would be make sense for the results that you report. Is that the data format you can recover?

If you are going after the old Agile Keychain Format, then I expect you are getting a 2x speed up from the bug we described in early 2013 (and discovered by the hashcat developers). But we are already deploying the successor of the successor of that data format.

This is where things start getting complicated.

First and foremost, we’ve seen both PBKDF2-HMAC-SHA1 (in old versions) and PBKDF2-HMAC-SHA512 (in new versions of 1Password). We’ve also seen PBKDF2-HMAC-SHA256, which appears in the following cases:

• 1Password10.sqlite (this database comes from the Windows desktop version or 1Password; we don’t support this format yet)
• B5.sqlite (this database is used in macOS for synchronizing with 1Password proprietary cloud service; we don’t support this format either)

In both cases, we’ve seen 100,000 rounds of hashing. We are working on adding support for these two formats to EDPR, expecting to see speeds that are similar to what we currently have (it’s not the hashing algorithm but the number of iterations that matters).

Finally, the profile.js (DropBox sync file) may use 20K to 200K iterations.

1Password supports several storage formats. The iOS app uses OnePassword.sqlite, the desktop version and browser plugins use 1Password10.sqlite (which is completely different from above, and is not currently supported as already noted).

In addition, 1Password supports DropBox and iCloud Drive sync. These cloud services receive a number of individual text files as opposed to a single SQLite database. Breaking the master password only requires a single file named profile.js (or encryptionKeys.js in older versions). Below is a sample:

var profile={"uuid":"id","updatedAt":date,"passwordHint":"","masterKey":"key","iterations":num,
lastUpdatedBy":"device","profileName":"default","salt":"salt","overviewKey":"key","createdAt":date};

The algorithm is the same as OPVault (currently PBKDF2-HMAC-SHA512; previously PBKDF2-HMAC-SHA1, like in older Agile Keychain format).

Finally, the number of iterations has always been variable. Moreover, the number of iterations appears to be dynamically calibrated, especially when using mobile version (no idea how it supposed to work for Dropbox sync). We don’t know the reasons and parameters for such calibrations.

The Story of Wrong Benchmarks

Why does 1Password need four different formats and three different algorithms (of which two are current)? We don’t know, but this is the reason why it took us so long to re-run the benchmarks and offer concise explanations. Were our original benchmarks wrong? Not for the latest version of 1Password. Our original benchmarks were measured using one of the four formats and one of the three algorithms supported by 1Password, which happened not to be the combination used in the current version of that password manager.

Long story short, we re-run the benchmark using the latest 1Password 6.8. Now it uses PBKDF2-HMAC-SHA512; iOS version database (extracted from iTunes backup) has 100,000 rounds, while DropBox-synced file opted for 60,000 rounds on our test iPhone 6S (hard to say how much iterations you will get, for example, when syncing older/slower iPhone models, but you can check that yourself, that’s pretty easy).

With these parameters, we came up with 3200 and 6000 passwords per seconds respectively using the same NVIDIA GeForce GTX 1080 board. Much, much better (for customers, I mean).

Our original benchmark had 95,000 passwords per second. This number was measured using a DropBox sync file produced by one of the older versions of 1Password with 10,000 rounds (PBKDF2-HMAC-SHA1). Other files we had (most of them) were using around 25,000 iterations.

This was definitely our error, and we bring our apologies to AgileBits. Rest assured that EDPR supports the latest builds of 1Password (with abovementioned exceptions) regardless of algorithms and the number of iterations. Our benchmarks were an order of magnitude wrong. However, adding a single character to the original password bumps the number of combinations to try by almost two orders of magnitude (considering the choice of all available letters, numbers and special characters).

Password Managers and Two-Factor Authentication

Some of our readers mentioned two-factor authentication as a roadblock to recovering master passwords. Please note that two-factor authentication is completely irrelevant here as we work with offline databases only.

Comparing to Microsoft Office?

You may think that we actually compared password managers to Microsoft Office. Of course, we did not. Those are very different tools, even if Excel is in fact used by many for keeping passwords (don’t ask us how we know). We don’t judge the software we break into. What we and our customers care about are the numbers allowing to guesstimate the time required to attack passwords of certain length.

Conclusion

Last but not least. Most modern password managers are very secure. If the entire password database is stored in the vendor’s cloud (e.g. 1Password, LastPass), it’s up to you whether to trust that vendor or not. We did not research the online part at all; our only job was adding support for local databases.

How can you make sure that your passwords are secure with either password manager?

• Use a strong (long and complex) master password
• Never write it down
• Safeguard your data, restrict physical access
• Bump up the number of rounds (hash iterations) if your password manager supports it to further decrease attack speeds
• Make sure you understand that if someone manages to break into your password manager, they will gain access to your every account. In addition, a chain attack may allow them to break in to your other accounts (for which you don’t store passwords with a password manager) by e.g. using single sign-on or recovering a password via email.