ElcomSoft blog

«…Everything you wanted to know about password recovery, data decryption,
mobile & cloud forensics…»

Attacking the 1Password Master Password Follow-Up

August 18th, 2017 by Vladimir Katalov
  • 41

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:


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.


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.


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,

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.


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.

  • 41

Tags: , , , , , ,

Sign up for free ElcomSoft Password Recovery Software newsletter

12 Responses to “Attacking the 1Password Master Password Follow-Up”

  1. kiralex says:

    Thanks to your article, I learned that I can modify the number of round in Lastpass. So, I set it to 200,000.
    I’m curious ; if a person have set the number of round to this value, how many password / second can you test with the config you use ?

    • Vladimir Katalov says:

      Assuming that’s the default value is 5,000, the speed will decrease in 50 times (dependency is almost linear). But you will get a notable delay when unlocking your vault the normal way, so I’d recommend you to play a bit with that value. I think 20,000 should be enough.

  2. phoerious says:

    > 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.

    That is actually the rather unexciting benchmark. Even against stronger human-chosen passwords, optimizations can vastly improve recovery times. The job of a good key derivation function is not only to slow down brute force attacks, but also to remedy the advantage you gain from more intelligent attacks by making both approaches infeasible. Only using raw brute force therefore makes your new results for 1Password as questionable as any of the other results. I also don’t know which application-specific optimizations you applied, but PBKDF2-HMAC-SHA512 is not a memory-hard function and can be optimized against with rather little memory footprint.

    • Vladimir Katalov says:

      First, our goal was not to impress someone 🙂

      On attacks: by brute-force, we meant (here!) not just the “classic” one with all possible combinations in a given range, but password recovery in general – with dictionary attack, attacks by mask, different mutations etc. All that is supported by our software, but outside the scope of this particular article, and not related to file format and hashing algorithm. We are talking about the speed only, in password per second – and does not matter what the password are and how they are generated.

      Finally, I am not sure what do you want to know on our optimisations and why you think the results are “questionable”. Is it possible to get better speed? Of course, yes, I think theoretically! We never said that our optimisations are the best or 100%, thought of course we do our best. You can easily check what speed do our competitors (there is a few) get, or even try to write your own implementation.

      Speaking of “crypto” part alone, I am sure that our implementation is good enough, and speed is close to maximum, while it might me still possible to increase it on 10-20%.

      There is a chance, however, that some application-specific optimisations are possible, especially for LastPass (go gain notably better speed). Our research never stops, and we will keep you updated.

      Still, I wanted to repeat that the numbers only about what speed *we* were able to get with *our* software, that’s it. That does not keen that it is the maximum speed theoretically possible. Also, the speed alone does not mean too much without reviewing all other aspects. We seen many file formats and configurations where password recovery is extremely slow, but it is possible to reset password instantly, gain access to some data without password at all etc.

      • phoerious says:

        The thing is that the passwords per second measure is rather uninteresting. Against non-memory hard functions, it’s basically just Moore’s law. Some functions are slower, some are faster, but if you throw more processing power in, they are basically all the same. At least try again against Argon2, Catena and the like and see how far you can optimize that. But generally more interesting would be actual recovery times of certain types of passwords. Otherwise I don’t care if you need a theoretical 2 billion years or only 600,000.

        • I partially agree. Well, when there are no vulnerabilities and no other options left (social engineering failed, no password re-use etc), brute-forcing is the only choice, still better than nothing, and gives at least some chance, especially if password is short or simple).

          Of course we will also implement support for new file format and encryption (though expect the speed to be extremely low there).

  3. B509 says:

    Incredible. I just found my 1Password encryptionKeys.js file synced to my Dropbox and checked the number of iterations: 1000 (!!!)

    Admittedly, I have been using 1Password for over a decade now but I would have thought 1Password would update the vault format and security regularly? If not, why not?

    • Vladimir Katalov says:

      That is strange, actually — we never seen less than 10,000 iterations. I would recommend you to delete that file (after saving its backup, of course — just in case), install the latest 1Password version and then sync again, so the new file will be created, hopefully with large number of iterations.

      1Password is updated on a regular basis, actually. I can only assume that this file was created some very slow (old) mobile device.

  4. paddad says:

    I also have a database only using 1,000 iterations. According to their website, this was standard until the end of 2011.


    Unless you change your password, you will stay at 1,000 iterations. After changing your password, it will increase to 10,000.

    The process to convert to the new file format involves typing console commands, or exporting your vault, creating a new vault, and importing the contents into the new vault. In my opinion, this should be much easier to perform so the average user doesn’t get stuck with an old vault that is more vulnerable to a high speed brute force attack.

  5. Clairvaux says:

    Did I miss the part where you stated the length of tested passwords ?