3 ms·
[Disclosure: I work for AgileBits, the makers of 1Password] The Agile Keychain Format was designed in 2007, and, indeed, it lacks both integrity checks and it
by jpgoldberg 13y ago
[Disclosure: I work for AgileBits, the makers of 1Password]
The Agile Keychain Format was designed in 2007, and, indeed, it lacks both integrity checks and it leaves sensitive information like URL and Title unencrypted. The newer format (first released in December 2012) uses authenticated encryption and keeps Location and Title (and must other data) fully encrypted.
As others have noted, the Agile Keychain is still in use. We are being very cautious in rolling out the new data format, as we need compatibility across all of the platforms we support. There is, as on most things, a document about this: http://learn.agilebits.com/1Password4/Security/rollout.html http://learn.agilebits.com/1Password4/Security/rollout.html
The rationale for the original design in the Agile Keychain Format is that the 1Password browser extension needs to be able to find which items match a particular website without having to decrypt everything in the database. Likewise, we'd like to be able to sort and provide an index of items without decrypting everything. The less we have decrypted at any one time the better.
The way we have solved this in 1Password 4 is to separate item information into "overview" and "details". The "overview" data is all encrypted with a common overview key. But the details of each item is encrypted with an individual item key, which in turn is encrypted with a master key.
By the way, 1Password has always documented what is and isn't encrypted. And we have shied away merely obfuscating unencrypted data. I will not speak directly about how other products handle the situation, but note that any password manager that integrates with the web browser faces a similar dilemma and have their own approaches.
At the risk of sounding whiney, I sometimes feel that we are taking more heat merely because we are more upfront about our design.