By using 1Password aren't you already completely trusting the developers?
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.
Yes, using 1Password means that you have to trust the developers. Open source would of course be preferable but the open source community has IMHO not managed to provide a comparable suite of apps. Personally, I am more worried about keychains as single points of failure.
Some time ago, the 1Password developers tried to explain why you should trust them:
KeePass is a software, not a service, so it doesn't really authenticate you. It uses a key to decrypt database, and that key derivation could be based upon various sources, including 2FA-like setups.
There are various plugins for multi-factor key derivation existing for at least several years already. You just have to chose one that suits you depending on what your second factor is (PKCS#11 token with RSA key, OATH HOTP generator, Bluetooth-based key storage, etc). Platform support may vary, though (so, not sure all options are supported, say, on Android).
1Password and KeyPass don't even do "one factor authentication". This is because you are not authenticating to any service as all. Your Master Passwords for these are "encryption" passwords not "authentication passwords".
Authentication is about proving your identity to a system that has the power to grant you access to something. They can have you go through multiple steps. But with 1Password and KeyPass, you already have full access to your data (it is on your disk). Your password is used not to prove your identity, but instead it is used to derive a key which can decrypt the data that you already have access to.
Services that you need to authenticate against face different sorts of threats than those which are based solely on encryption. An authentication system protecting high value data simultaneously make multi factor authentication possible and necessary. For encryption based systems, MFA literally makes no sense.
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.
'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.'
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.
[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
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.
"We have been laying the groundwork to remedy this for quite some time...but it is impossible to predict when any particular mile post will be reached."
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.
It is impossible to explain why 1Password data on Dropbox can be in such odd locations without discussing history, but the short answer is that we originally allowed 1Password users to place their data anywhere they wished on Dropbox. In order to help 1Password actually find where that data is, we also had it write the location into a file at the root of the Dropbox folder, in a file called .ws.agile.1Password.settings.
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?
Presumably it's so that when you set up your second machine, it can find your 1Password keychain automatically without requiring you to tell it explicitly where it is.
Why not just create a separate Dropbox account strictly for your 1password files? It's free anyway, and then you don't have to worry about then getting access to more information than they really need.
If your 1Password usage is limited to Apple devices, iCloud is another alternative. But since the 1Password keychain is encrypted, it should not matter where you store it in the end.
I believe the answer is no, but that's irrelevant. You could grant permission on the dummy account and then share the folder with your real account so it would show up.
No that won't work. 1Password on Mac/Windows does not talk to Dropbox.com directly. They know where your Dropbox folder is on your computer, and go play with it directly.
And if they change this, my iPad1's old version of Dropbox will break. That's why they're stuck: they will have to fix 1Password on all platforms.
I think this has now changed. Back in September they changed the way in which Dropbox sync worked, when Dropbox retired their old APIs.
Many people were left with iOS and Android devices that no longer synced. Annoyingly they had launched a new iOS app and removed the old one from the AppStore. Users were left with the only option to 'rebuy' the app again.
Many users were pissed by AgileBits decision to do this. They blamed the Apple policy of not being able to update withdrawn apps, but to most people that smelled of horseshit.
I think that all of their apps now use the new Dropbox API. Old versions of the 1password app on iPad still work, but don't sync. It isn't immediately obvious though until you look to use a new secure note created on the PC and find it missing on the iPad.
This, and the (at least practical) inability to read the source of 1PasswordAnywhere (which I often want to use from a machine in my house/a friends house without 1password installed, etc) is why I made Mr. Password. It also uses Dropbox, but it uses the Datastore API (so it can only access it's own data), and it's open source.
I work for AgileBits. As the document you linked to explains, this is an accident of history that we would love to undo. It is hard to provide the user flexibility that people want in selecting their data location.
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.
BTW, what happened to Dropbox becoming an iCloud alternative?
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 …)
We've had this same problem at Blogvio. Users asked us why we need access to their entire Dropbox. And indeed we didn't need - but we didn't know better either.
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! :-)
If I understand this article correctly the problem isn't the missing permission type provided by dropbox but the location of the settings file which was placed on the root level of your dropbox (for historic reasons). There's currently no way to access /dropbox/mythings/morethings/onepasswordfolder and /.onepasswordsettingsfile so they need to get access to / to keep the historic file at root level working.
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.
The bigger issue (at least to me) is that Dropbox, and every other application granted Dropbox access, has access to your encrypted 1Password datafile. It's why I don't use cloud services to sync my 1Password file.
The whole point of encryption is that you can give it to a malicious third party and they won't be able to see what's inside. Why would this be an issue for you?
Because things that are difficult to decrypt eventually become less difficult to decrypt as computing power catches up with encryption complexity ... and a static datafile provides no protection against fast-as-you-can brute-force decryption attempts.
Every application granted Dropbox access doesn't necessarily have access to the 1Password datafile. I use several applications which only have permission to read/write to Dropbox/Apps/[App Name].
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.