I mean, it's a proprietary application that you use to store all your passwords and other sensitive data. I'm pretty sure having read/write access to your dropbox folder is the least of your worries if the developers had malicious intentions.
Some time ago, the 1Password developers tried to explain why you should trust them:
http://blog.agilebits.com/2013/09/06/1password-and-the-crypt...
In addition, http://learn.agilebits.com/1Password4/Security/keychain-desi... might be interesting with regard to your question.
And these are values I very much respect, and I promise I won't act surprised when I get screwed by using proprietary software.
But in terms of user experience, I can't inflict KeePass on the people in my company, especially any non-Windows version.
If you want to train people to handle passwords responsibly, user experience is extremely important, and having to use KeePass would be a punishment.
People would start finding ways to not use it, which is why 1Password is the safer choice in practice, despite being proprietary.
'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.'
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.
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
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.
If the file just contains a pointer to a subdirectory, why does it need to be stored on the user's Dropbox account at all? Couldn't they keep track of the preferred Dropbox folder themselves, on a per-user basis?
Disclaimer: I don't know anything about Dropbox permissions or their API, I'm just judging this by reading the article.
Edit: And now that I re-read the parent comment it seems that maybe I misunderstood your comment and it's already possible to have different permissions at different locations.
http://discussions.agilebits.com/discussion/comment/112937/#...
Impossible to give a date with both high precision & accuracy, maybe, but certainly not impossible to predict. Statements like that would give me pause were I were trusting AgileBits to protect my secrets.
We don't want to train people to ignore things like the Dropbox notification nor do we like violating the principle of least authority. But until we find a way out of this mess without seriously disrupting things for a very large number of users, we are stuck with it.
We don't usually reveal company internal processes, but I am personally to blame for this situation. When we first started explicit Dropbox integration, we discussed whether we should force a specific Dropbox location for all 1Password data. We had a number of power users who had some unusual set-ups and wanted to organize their Dropbox data as they wished. I pushed for supporting those power users. In retrospect that was a bad idea, but this was before the days of any real Dropbox sandboxing.
I rarely use Dropbox to sync app data because it's always fully visible in Dropbox and messes up my directory structure. (Although chflags hidden usually helps …)
After a bit of research we found out we can have a specific folder set to Blogvio that would sync with the system. And that, combined with something like Zapier is a much better solution that we envisioned first. Learning by mistakes! :-)
