Feature Request: Sync service delivered by AgileBits

Maroder

Hi,

How about a Sync service delivered directly by AgileBits? This would make the Dropbox/iCloud crutch redundant for syncing multiple devices with different operating systems and would give us a pure sync option instead. Directly from the makers of this great software.

This of course could be offered optional to the existing sync methods for a small monthly fee. As long as security aspects are considered thoroughly I would be a paying customer at once as I hate using my Dropbox for password syncing (Windows, iOS, OSX and Android). Just a thought :-)

Cheers,
Maroder

RichardPayne

How is an Agilebits provided sync service any more or less of a crutch than using Dropbox?

And why do you hate using Dropbox?

Maroder

It would be no cruch, because it would be a build-in, dedicated service with support for all plattforms.

I may prefer OneDrive or Google Drive but still have to use Dropbox for sync on my iOS devices. My preferences may change in the future and an independent dedicated and built-in service would fit my need more than being bound to only supported cloud storage services.

RichardPayne

So you comparing the following setups:

1) OneDrive/GoogleDrive + Dropbox
2) OneDrive/GoogleDrive + AgileCloud

I don't see where the benefit to you would be in option 2. You'd still need to manage two cloud accounts.
Granted, on Windows and Mac right now you need the Dropbox app installed, but there are apis for it so the 1Password app could be made to talk directly to Dropbox.

On the downside you're asking Agilebits to take on a rather large development task in an area that is new to them in a market which is currently in price war. You may be willing to pay for such a service but given that Dropbox is free I suspect that you'd be in the minority.

Megan

Hi @Maroder,

Thanks so much for the suggestion! As @RichardPayne‌ says, it's certainly not a simple task and there are a multitude of things to consider, but it's great to know that there is interest in something like this.

Maroder

@RichardPayne‌
As I see it here acutally would be two benefits.

1. The user doesn't have to rely on specific cloud storage providers for sync between multiple devices. It would just work on every major OS as intended.
2. For AgileBits it would be a huge simplification once their sync process was established. Having to rely on the different APIs and cloud storage solutions for syncing options can't be easy to support. Look how long GoogleDrive sync support is taking even as this is heavily requested by 1Password users.

@‌Megan
Glad to give feedback. Of course the development of an own sync process would be a major task but in the end it would make 1Password a more independent and complete solution.

hawkmoth

I'll just toss out that one of the advantages that 1Password touts is that they never know you password and never have control of your data. If you used their own cloud solution, they would then have control of your data. I like it like that.

Maroder

@hawkmoth‌ Security aspects should be considered thoroughly. The encryption should happen before transfer, so not even they could encrypt the database without brute forcing it for ages. Also it always could be an optional feature.

hawkmoth

I'm confident enough of my master password that I don't worry where my data reside in the cloud. The master password is the real security anyway. It needs to withstand an attack if someone were to steal my computer and go after the local copy.

RichardPayne

+! @hawkmoth‌

The user doesn't have to rely on specific cloud storage providers for sync between multiple devices. It would just work on every major OS as intended.

An Agilebits provided sync would still be a "specific cloud storage". Remember that there is no authentication process associated with 1Password as it standard. So to has 1Password storage stuff in an Agilebits provided cloud you'd have to create a cloud account on their website and then provide the credentials to 1Password. This is really no simpler than the current setups.

For AgileBits it would be a huge simplification once their sync process was established. Having to rely on the different APIs and cloud storage solutions for syncing options can't be easy to support. Look how long GoogleDrive sync support is taking even as this is heavily requested by 1Password users.

This would be true if all users were happy using the service. However, given that many of the complaints about the lack of GoogleDrive and OneDrive support that get posted here seem to relate to people not wanting to have more than one cloud account. Given this, an Agilebits cloud service would need to be provided as an extra option alongside Dropbox and iCloud. Basically it just adds unnnecessary complexity.

AppleTim

@Megan I'd like to chime in to also request a sync service provided directly by AgileBits. This would be huge, as the average, non-technical user could have an "it just works" type of experience across their devices. I think of someone like my grandmother who would want an easy account setup....a la Facebook, Evernote, etc. But today, if I say to her "go buy 1Password and keep all your important stuff there", she would hit a stopping point at the dropbox or iCloud piece.

Drew_AG

Thanks for your feedback, @AppleTim. We really appreciate it! :)

jpgoldberg

There are a couple of security concerns that we would have with offering our own sync service.

We must not have the ability to learn your Master Password.

Presumably the ease of use and simplicity of set up would mean that your 1Password Master Password would be used (indirectly) both for encrypting your data and for authenticating with our sync service. Typically (but not necessarily) when you authenticate with some remote system, you send your login password to that remote system. Thus it is possible for Dropbox to learn your Dropbox password, or for this to be attacked in transit.

Our current design is to never use your Master Password for authentication, so that dramatically limits the scope of it being captured by us or by anyone else. So if we were to build our own sync service, we would need to do so in a way in which we can ensure that it does not expose your Master Password to additional threats.

Of course there are protocols that can be used in which the server learns little about the login password. Something of that nature would need to be used.

We become a big juicy target

Sure things like iCloud and Dropbox are routinely targeted, but something built specifically for 1Password data is going to be a desirable target. We would need to acquire the skills needed to defend such a system from a huge range of attacks.

The best defense, of course, is having nothing worth stealing. That is we would
need to build the system so that it is like how Michael Lucas describes Colin Percival's Tarsnap (Secure remote backup for Unix-like systems).

Tarsnap's design lets Colin fully comply with any legal, quasi-legal or blackmail-driven demands while being utterly unhelpful.

Only by being able to demonstrate to the world that we hold nothing an attacker my want, can we reduce the kinds of attacks that we would face.

Master Passwords may not be strong enough

There are fundamental limits of what can be done with things like PBKDF2. (This is because PBKDF2's work factor rises the same for the attacker and the defender), so if people do not use good Master Passwords, our data would still be valuable to an attacker with sufficient cracking resources. So we need to make any data that we store not just "hard to crack" if it falls into the wrong hands, but fundamentally uncrackable.

Again, this can be achieved. If there is some high entropy secret that is never pushed to our sync service, but is required in the key derivation, than Master Password cracking of data that we store is out of the question.

This sort of "second factor key splitting" has been talked about a lot in the forums. The two big problems with it are that (a) loss or damage of this second key would completely lock people out of their data, and (b) the user would be responsible for getting this second key to all of the devices that they use 1Password from. (After all, the whole point is that it is not stored on our systems).

Again, this isn't insurmountable, but it is something that adds complexity in usage and puts a burden on the user. Although such a thing could be offered "optionally", we would be uncomfortable with that if part of our goal is to not be a useful target.

Trusting x509 for server authentication?

I don't think we would want to trust the x509 (SSL/TLS) trust infrastructure to avoid man in the middle attacks. That is are normal checks on site certificates enough to ensure that you are really talking to our sync service?

While I think that we would certainly use SSL/TLS, and perhaps with some certificate pinning, I do not believe that we should rely on it entirely. So we would need to build in an additional layer of server authentication (and perhaps encryption above SSL/TLS and our normal data encryption) for the communication.

Again, this isn't impossible. Password-based Authenticated Key Exchange (PAKE) protocol could be used, but again this is a lot of new stuff to develop. PAKEs all involve the underlying math used in public key cryptography, and this is a level of complexity that we have so far avoided.

Retaining "Privacy By Design"

One of the things that helps distinguish 1Password is that is build with Privacy By Design. We would want to ensure that our own sync service complied with those design principles. Pretty much all of the security things I've listed above are instances of what we would need to do to stick to our overall security philosophy.

Again, none of that is impossible. But it does require much more than just a file-based sync service.

s7000

I'd also like to chime in on this request.

Being new to Dropbox Sync, I have to admit it works really well, but there are still security concerns associated with Dropbox. Data not being encrypted end-to-end, being exposed in a plain format while being transferred inside the Dropbox infrastructure (using Amazon cloud services if I'm right), staff having access to unencrypted data and so on. So there definitely is some demand to do better than that.

One might say security of a cloud service does not matter as long as personal data is encrypted before being stored in the cloud. Indeed. But according to an analysis of the 1Password data uploaded to Dropbox, only the credentials are actually encrypted, but the login URLs are not. Some people may decide even the existence of their account at some site is personal data to be protected - not just the password itself. So again, there is some demand to do better than that.

jpgoldberg

Those are excellent points, @s7000.

The migration away from the Agile Keychain Format (which leaves item Titles and URLs unencrypted) has been frustratingly slow for everyone. But this is separate from the question of whether we run our own sync service. That is, we need to phase out the Agile Keychain Format whether or not we run our own sync service.

A minor correct that doesn't take away from your broader point. It is not "only" the credentials that are encrypted with in the Agile Keychain format. Pretty much everything that doesn't show up in an index list is encrypted. So things like secure notes, attachments, etc are all encrypted.

s7000

Upgrading the Agile Keychain to a fully encrypted format would actually be a compelling perspective, @jpgoldberg.
Indeed I would definitely have less concerns using standard cloud services then.

jpgoldberg

I really wish I could promise a date for the phase out of the Agile Keychain. We have one platform which doesn't (yet) understand the OPVault format, and our last, limited, attempt to test a migration from the the Agile Keychain to OPVault revealed a bug in the handling of attachments, and left some of our testers with attachments that they could not decrypt.

So, once again, I can't promise a date, but I can say that there is a lot of progress, even if most of it is behind the scenes.