Does this mean non-cloud sync is going away?

dougl

From these comments: https://blog.agilebits.com/2017/02/19/1password-for-mac-6-5-5-manual-update-required/#comment-7378

Can you confirm that local (non-cloud) syncing will continue to be supported on iOS and OS X?

If you need to shift to subscriptions for business reasons, I understand - but that's a separate need from requiring cloud storage of credentials.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Pilar

Hi @dougl

Thank you for getting in touch with us :chuffed: First of all I'd like to tell you a bit more about 1Password.com accounts and why they're here. It all began because companies needed an easier solution than the one we had syncing with Dropbox and having to jump through hoops to share a vault. It was hard, time consuming and we often couldn't help because it relied on an external tool. So 1Password Teams came to life. Some people saw what it could do and decided to do use it with their family, and asked an appropriate way to pay for it, so we listened and launched 1Password Families. But who wouldn't like automatic, hassle free syncing and having access to their accounts online? So again, a lot of people asked for an individual plan and we delivered ;) If you're now wondering why I got into all these details is just so you know that we didn't develop 1Password.com accounts with the idea of how we got revenue in mind but with what our customers wanted, and what we thought would give most people the best 1Password experience possible out there.

I'm going to guess that you're concern is security related, right? If that's the case then I'd love to talk about how 1Password.com accounts keep your data safe. The short answer is that on top of the Master Password that you know we have a Secret Key that is _ combined_ with your Master Password to encrypt all of your data. Your Secret Key is a random string generated directly on your device, and when combined with your Master Password it renders your data mathematically impossible to decrypt even with all the money of the world available. Please tell me if you'd like to learn some more about our security model, as I love talking about it!

That being said, I'd like to tell you that while we do not have plans to remove the current functionality for local vaults existing in 1Password I can't promise either that we'll be able to maintain them forever. We don't know what the future will hold and making promises about any feature in 1Password wouldn't really be fair :)

If you have any questions, or would like to learn more about anything I mentioned just let us know!

MrC

Please keep in mind, there are certain business entities that will not, and cannot, use cloud-based services. They are subject to the rules and demands of their clients and IT departments, and no amount of your explaining "how 1Password.com accounts keep your data safe" will satisfy their objections and valid reasons. Not until Agilebits guarantees data safety, backed by eight or nine figure bonds for assurance against potential lawsuits, will some of these firms start to consider your cloud services.

dougl

Hi Pilar, I'm actually a security architect for one of the largest security vendors in the world. We went through this with you folks a few years back, and I'm surprised to see that you're backtracking again.

MrC's comments are dead on right - from a corporate standpoint, we can only use fully vetted and approved solutions, and that requires a specific contract outlining T's and C's, including liability. Enterprise cloud is a different ball of wax.

From a personal standpoint, no offense, but I know how hard it is to both get crypto and cloud right. For my needs, your EULA does not include sufficient protections for end users if you suffer a breach. It's a consumer cloud solution. To be fair, for users who don't use a manager at all, adopting your cloud is probably better than status quo, and I certainly have coached my audiences on exactly that point.

As an aside, when I see the word 'impossible' used, it raises my eyebrows. Recovering the key is not impossible (brute force is always an option) - functionally impractical sure, but only from an algorithmic standpoint. The risk is that there is a defect in the implementation code that renders recovery much easier than brute force. You guys are very good, but crypto is dammed hard to get perfect. With a local vault, the attacker not only has to compromise the algorithm, they also have to compromise my machine and gain access to the file. With a cloud solution, there's a critical mass of vaults in one place, which changes the cyber economic case and makes it a very tempting target. Dropbox has even worse risk than your own cloud service, so it's a complete non-option.

Perhaps, if you completed a full third-party security audit (and the audit would have to be repeated for every new release), and added sufficient liability in the EULA, I might consider your cloud, but short of that it's a non-starter. My password vault truly is my crown jewel, and a disclosure would be catastrophic. I'd even settle for an 'agile bits server' requirement - I can fire that up when on a trusted network, run the sync, and then turn it off. That would allow you to use the same code as you do for the cloud sync, just with a different URL.

By the way, please don't apologize for a subscription model - it's what my own company is moving towards, as it guarantees a revenue stream. Adobe and Microsoft have done the same. I gain sufficient value from your product that I'd gladly subscribe, but only if it meets my security needs - which includes local sync.

I'd urge you to retain, and affirm, local sync as part of your long-term strategy.

AGAlumB

@MrC: I think it's safe to say that doesn't apply to most users, but that's a really good point.

@dougl: Yeah, "impossible" probably isn't the best word. I'm sure you can appreciate that for all intents and purposes it is though (and if you can prove otherwise, we'll make it worth your while). I agree that "infeasible" is more appropriate. And since we're splitting hairs I don't have already, I think it's important to keep in mind that a EULA doesn't actually keep anyone's data safe; only encryption does. Contracts, after all, can be broken, and often are. Brute force is possible only in the sense that it could happen eventually if you crank at it long enough, but not on a reasonable timescale. Even if we collectively had the machinery to brute force the Account Key, we do not globally possess the means of generating enough power in a short enough time to matter. Even with enough potential computing power, you'd need to be able to turn them all on and keep them running long enough.

You're right that the hosted service is a much bigger and more exciting target than any individual user could ever be, and exposed in the sense that it's on the public internet. But this isn't a surprise to us, and has very much informed the design. Even if our servers are compromised and the database dumped, we simply don't have what an attacker needs (which is actually a bit different than if they come after you individually, since they can reasonably assume that you have the keys, and could probably find ways of getting what they want from you if sufficiently motivated). So when you use 1Password, AgileBits never has the keys to your data, regardless of the setup you choose. That hasn't changed. Even with 1Password.com, your data is encrypted on your device, so the server is storing an encrypted blob. And since the Account Key is created locally, your Master Password is only known by you, and neither is ever transmitted, no one — including AgileBits — has the means to decrypt the data. You can read more details on how all of this works in our white paper and ask any questions you might have.

I realize that this may not be of use to you now given contractual obligations, but it's pretty important that we don't take these things for granted. Thanks for letting us know what's important to you. And while I don't have any news that will be of interest to you at this time, we are looking into the possibility of offering a self-hosted option in the future. If that's something that might interest you, shoot us an email at support@1password.com and we can stay in touch. Cheers! :)

dougl

Thanks for the note back. Couple of thoughts:

I think I wasn't clear: I do trust the crypto algorithms (math), and know you folks have a good handle on the nuances. But converting that into code is a different story - one mistake in design or coding, can result in a significantly easier attack. In the absence of a third-party audit, that risk is even higher. So the threat is that a hacker penetrates the cloud service, steals and stores the vaults until a defect is uncovered, cryptanalysis techniques improve, or computing power increases - at which point, decryption becomes practical. Granted, it's a low-probability event, but since the impact is catastrophic, the overall risk is high. If I'm specifically targeted, it's one thing (and difficult to avoid), but at least it's a one-off effort. Hoovering up vaults en-mass is a different calculation.

Regarding the EULA: Risk can be mitigated, accepted or transferred. In this case, an improved EULA (or other contract) is a compensating control - it transfers the risk - currently 100% on the consumer - to a shared risk by both organizations.

That, by the way, is why I don't use iCloud, Gmail, or similar consumer-grade cloud services as a sole repository for my data (or for sensitive information, at all) - those EULA's have absolutely no consequences to the provider if there is a breach and disclosure.

I'll contact you via support to talk about the locally hosted option.

For the record: I picked, and recommend, Agilebits specifically because of your responsiveness, understanding of crypto, cross-platform support, and the local sync option - your competition, which is cloud only, doesn't cut it.

AGAlumB

@dougl: Good points. But I think it's important to keep in mind that we're not rolling our own crypto. A lot of companies try to reinvent the wheel in this area because, frankly, it's fun and cool. But when a robust, time-tested technology like AES (which has been vetted over decades) exists already, we'd be taking a huge risk trying to invent something comparable ourselves, because you're 100% right: we're only human and could make mistakes doing so. It's just too important that it be secure now rather than hoping we get it right and only finding out that we didn't once it's too late.

I didn't mean to say that EULAs don't have their place. Often they're a requirement due to contractual obligations, etc. I just think it matters that we don't give them more weight than what they offer. This is definitely an area we're paying attention to though, and hopefully we'll be able to offer a self-hosted option in the future as well. Thanks so much for your support, and for caring enough to ask the tough questions. We're lucky to have such passionate, security-conscious customers! :)

dougl

Never said you were rolling your own crypto algorithms. But you do write your own code (or someone does). AES is an algorithm, not code, and the latter is where the devil meets the details. So we have all the usual risk of code vulnerabilities (my company sells one of the top source and dynamic code scanning solutions for what it's worth) associated with a locally used application, we have a much larger threat footprint with a cloud service.

Net though, I hear what you're saying - let me summarize to make sure I understand the important bits (no pun intended) :-)

1) No plans to remove local wifi sync options from the mac or IOS clients any time soon.
2) Looking at local sync server option for a future enhancement

As long as 2 happens before 1, life's all good :-)

Cheers!

AGAlumB

Ah, I'm sorry I wasn't more specific too. We're not writing our own AES implementation but rather using standard libraries.

Indeed, we generally remove features unless there's something flat out broken or there's a security concern. For example, we removed the insecure item sharing feature for a month or so a while back (which was later re-introduced due to user feedback with sufficient warnings in place). That's the only case I can think of off the top of my head.

We definitely don't have plans to remove sync features, as that would require more effort than leaving them there, especially since folks are using them now, and frankly we've got our hands full anyway.

Self-hosted 1Password Accounts aren't a sure thing and most likely a ways off even if it is a direction we go, but the only way it will happen is if there's enough interest and we have a good sense of our customers' needs there. :)