On The Security of Password Manager Database Formats

Maceage

Hi AgileBits,

Are you aware of the following PDF document that compares various Password Manager Database Formats?
https://www.cs.ox.ac.uk/files/6487/pwvault.pdf

I'm not sure when the document was published but it makes for interesting reading, especially where 1Password is concerned:

Format Description.
1Password stores its database in multiple files. Each file contains a database entry, stored in JavaScript Object Notation (JSON). Entries are listed in an index file called “content.js”. 1Password allows users to select a different “security level” for each record [3].

The lowest security level corresponds to unencrypted entries, while the highest level means that sensitive fields, such as username and password, are encrypted with a key derived from the user’s master password. Regardless of the security level, some fields, e.g., the title of an entry, are never encrypted. We analyze the protection offered by the highest security level.

The encryption scheme used is AES-128 in CBC mode. Neither the records nor the index file are integrity protected. As a result, database corruption is only detected when the JSON parser fails to process the database.

Security Analysis.
1Password’s database format is affected by vulnerabilities that give adversaries a non-negligible advantage in both the IND-CDBA and
MAL-CDBA games. Advr can win IND-CDBA with probability 1 as follows: Advr builds two samesize record-sets RS0, RS1 such that there exist two records r0, r1 from RS0 and RS1 respectively, which differ in at least one of the following fields: title, location, locationKey, createdAt, updatedAt or typeName. These fields correspond to: the title of the record, the record URL, the URL used by the browser plugin to perform auto-complete, the time of creation and last update and the type of record (e.g., web form, protected note, credit card information). Since these fields are never encrypted, Advr can trivially determine bit b by testing which record belongs to DBb. In practice this means that an adversary with access to a 1Password database can read these fields and thus gather sensitive information about the user’s browsing habits.

Advrw can win the MAL-CDBA game with probability 1 as follows. Advrw selects an arbitrary record-set RS and receives the corresponding database DB. Then, Advrw can (1) alter any of the fields listed above, and/or (2) remove any entry by deleting the corresponding database file and altering the “content.js” index file correspondingly. In general, as long as the database is still composed of a set of correct JSON strings, 1Password will not show any warning. In practice, this means that an adversary can mount phishing attacks by replacing a legitimate URL with one pointing to an adversary-controlled website.

Additionally, if Advrw outputs at least two record-sets, say RS 6= RS0 and receives the corresponding databases DB, DB0 in the MAL-CDBA game, it can construct DB00 selecting records from both DB and DB0. This allows an adversary, among other things, to replace individual records in a database with older versions.

From reading this, it sounds like plain-text URLs are the issue - Is there any way you guys can encrypt URLs?

Being a software developer by trade, I know you've probably left those as plain-text to facilitate lookups from the browser when you're on a specific page. However, is there no way you could encrypt those URLs on save and decrypt/cache them for lookups? Surely that would negate the assumptions made above and provide better overall security for 1Password?

Regards,
Graham

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Ben

Hi @Maceage

Thanks for taking the time to write in with this concern. We have long been aware of the issue with unencrypted meta data in the Agile Keychain sync format. Modern versions of 1Password now default to the newer OPVault format when using 1Password standalone, and likewise the 1Password.com service is not affected by this:

AgileBits Blog | When a Leak Isn’t a Leak

I hope that helps!

Ben

Maceage

Gotcha - thanks for getting back to me. Like I say, I'm unsure when that document was written :)

Regards,
Graham

Ben

You're very welcome. :+1: :)

Ben

pervel

Looking at the references at the end of the article it looks like they are referring to 1Password version 3.

AGAlumB

Ah, that explains it. What's weird though is that a couple of their references are dated 2012, so this seems to have been written about 1Password 3 after it was discontinued. Oh well.

jpgoldberg

Hi @Maceage! That was an outstanding paper, and the authors send us a draft of it prior to publication. I remember it and the conversations I had with the authors fondly.

That paper looks at the Agile Keychain data format, and points out several of its known shortcomings. OPVault, the successor to the AgileKeychain, addresses the two principle concerns: The lack of encryption on Location and Title, and the unauthenticated encryption modes. OPVault was first introduced in late 2012.

With 1Password Accounts, we have improved on the OPVault as well. But in terms of cryptography, the big jump was from Agile Keychain to OPVault.

If I may, I would like to quote from the OPVault design document

When the Agile Keychain format was developed, chosen ciphertext attacks (CCA) were seen as theoretical. Furthermore, the primary threat to 1Password users was thought to be from an attacker stealing the data once and pursuing an off-line attack. It did not anticipate an attacker who could tamper with user data that would be subsequently processed by the legitimate owner.

CCAs are no longer just theoretical, and we also see (and encourage) widespread storage of 1Password data in “the cloud” for syncing. Thus, data integrity needs to be addressed in our new design.

Instead of trying to design against particular CCAs or particular mischief that can be done through data manipulation, we simply authenticate everything we can. Authenticated encryption is used whenever we encrypt, and HMACs are calculated over the elements in each item. The item is rejected if the MAC does not verify. The Encrypt-then-MAC construction is better thought of as “Verify-and-only-then-Decrypt”.

Maceage

Thanks for getting back to me with a greater explanation @jpgoldberg.

Like I say, I wasn't sure when the white paper was written - a colleague at work linked to it and I just thought it worth posting here :)

Anyhow, I've since upgraded my 1Password vault to the OPVault format so hopefully nothing to worry about there!
Have taken a good read of the documentation around the OPVault format and it seems much better than Agile Keychain.

I do have one question though - I only started using 1Password about 2 years ago and I sync my vault with Dropbox.
Why would my initial vault have been created using the Agile Keychain format? Was that the default format when users were syncing with Dropbox? I'm not sure whether I first created the vault on my Mac, my Windows PC or my iPhone.

Regards,
Graham

Ben

Why would my initial vault have been created using the Agile Keychain format? Was that the default format when users were syncing with Dropbox? I'm not sure whether I first created the vault on my Mac, my Windows PC or my iPhone.

I suspect your assumption here is correct. Without knowing exactly when/what version of 1Password you were using at the time it is hard to say, but OPVault didn't become the default until e.x. 1Password for Mac v6.0 released 2016-01-12.

Thanks!

Ben