3 ms·

Look at the 1Password database files. They appear to be JSON, with no integrity mechanism, with many unencrypted fields. I have to wonder if the clients handle

by Canada 13y ago

Look at the 1Password database files. They appear to be JSON, with no integrity mechanism, with many unencrypted fields. I have to wonder if the clients handle this data safely, and why they choose to encrypt only certain fields. It doesn't give me a lot of confidence.

chmars 13y ago
See http://learn.agilebits.com/1Password4/Security/keychain-design.html http://learn.agilebits.com/1Password4/Security/keychain-desi... for more information on the keychain design, in particular: 'Some metadata remains unencrypted: Which folder an item is in; what category (Login, Credit Card, …) an item belongs to; creation time; modify time; and last sync time. The item UUIDs are fully available, which can be used to determine how many attachments, if any, an item has associated with it. The UUID of any folder an item belongs to is unencrypted, and thus an attacker can determine which items are in the same folder.'
- Canada 13y ago
  Yeah, I saw that, and I believe it to be a poor design decision. They say, "The Agile Keychain kept some information (most notably Location and Title) unencrypted so that these could be used to search for or identify a particular item, while the more sensitive content could remain encrypted." The Windows and OS X clients, as well as the Firefox and Chrome plugins, if not all of their software, doesn't allow this search to occur unless the database is unlocked anyway. So 1Password leaks the list of sites you are storing logins for, in exchange for zero benefit. Users with different logins to the same site will probably put usernames in the titles to differentiate those entries, so 1Password is surely leaking a lot of usernames as well. The design document goes on to say, "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." That was a reasonable assumption when the database was stored locally, but is not OK when you store it with an untrustworthy third party such as Dropbox. Their document talks about HMAC, but I get the feeling this is limited to the content of the encrypted fields. Even then, look at files such as "contents". It leaks all kinds of sensitive information. It also concerns me that 1Password data files seem very adhoc. Sometimes JSON, sometimes XML. The clients watch for file changes and re-reads automatically. It potentially exposes the app to malicious databases. If I were assessing these applications I'd start by fuzzing these JSON and XML files.
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.

by Canada 13y ago

chmars 13y ago

See http://learn.agilebits.com/1Password4/Security/keychain-design.html http://learn.agilebits.com/1Password4/Security/keychain-desi... for more information on the keychain design, in particular: 'Some metadata remains unencrypted: Which folder an item is in; what category (Login, Credit Card, …) an item belongs to; creation time; modify time; and last sync time. The item UUIDs are fully available, which can be used to determine how many attachments, if any, an item has associated with it. The UUID of any folder an item belongs to is unencrypted, and thus an attacker can determine which items are in the same folder.'

Canada 13y ago
Yeah, I saw that, and I believe it to be a poor design decision. They say, "The Agile Keychain kept some information (most notably Location and Title) unencrypted so that these could be used to search for or identify a particular item, while the more sensitive content could remain encrypted." The Windows and OS X clients, as well as the Firefox and Chrome plugins, if not all of their software, doesn't allow this search to occur unless the database is unlocked anyway. So 1Password leaks the list of sites you are storing logins for, in exchange for zero benefit. Users with different logins to the same site will probably put usernames in the titles to differentiate those entries, so 1Password is surely leaking a lot of usernames as well. The design document goes on to say, "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." That was a reasonable assumption when the database was stored locally, but is not OK when you store it with an untrustworthy third party such as Dropbox. Their document talks about HMAC, but I get the feeling this is limited to the content of the encrypted fields. Even then, look at files such as "contents". It leaks all kinds of sensitive information. It also concerns me that 1Password data files seem very adhoc. Sometimes JSON, sometimes XML. The clients watch for file changes and re-reads automatically. It potentially exposes the app to malicious databases. If I were assessing these applications I'd start by fuzzing these JSON and XML files.

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.