Plan in the works for account administration to be placed inside signed executables?

I'm a user currently of the cloud account model. Certainly, the 1PW cloud model ("+2SKD", as @jpgoldberg calls it) is downright awesome and probably one of the most innovative of models streamlining encryption in transit and authentication in one go. I appreciate very much the time, effort, and thought put into authentication using SRP instead of stored hashes, double encrypting inside TLS with the static SRP secret, and doing key derivation and encryption steps locally. I appreciate the usability you have created in team/families account recovery and vault sharing as well.

But our 1PW accounts are definitely central points of failure - in fact, the most destructive central points of failure that your users can have. Certainly, I'd rather an attacker have access to my bank account than my 1PW account; at least I have the legal grounding to recover from financial identity theft.

Which brings me to account administration: the web-based administration interface which we must use and for which we have no signed-code alternative. As cloud account users, the fact that we have no choice but to do all essential account-administrative tasks by browser, running js served from Cloudflare endpoints, with TLS (dissolving inside the CF reverse proxies, not even inside your own servers) being our only halfway assurance that I know that the js running is non-malicious. And we have to enter both our account key and master key into it - everything needed for a complete disaster. As @jpgoldberg says himself in "Beware of the Leopard", delivering code via browser is always a problem.

So it would seem to me that as long as someone is using the web interface on a semi-/regular basis, the rest of the awesome transit and asymmetric+symmetric+SRP key wrapping architecture you've carefully built (which I appreciate) doesn't even matter - a single large vulnerability in TLS, or a compromise in a Cloudflare endpoint, could compromise many of your users at the same time, because malicious code could then be delivered, negating everything else.

Are there plans in the works for account administration to be embedded into your signed executables. on all platforms? Because until then, it's anxiety-inducing every time I have to log into the web interface.


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

Comments

  • jpgoldbergjpgoldberg Agile Customer Care

    AgileBits Team Member

    You have asked an extremely important question, @analogisttr

    Short answer

    The short answer is that yes, there are plans but we can't even begin to make a whisper of a hint about when this might be available.

    The problem you raise

    You are absolutely correct that when using the web-client the security of the whole thing depends on the integrity of the TLS connection. Someone who can modify or inject traffic to your browser will be able to inject a malicious client.

    Slightly longer answer

    There are, roughly, three approaches we are pursuing simultaneously. The first is to bring more administrate capabilities to our native clients. The second is the package our existing web client into a signable download. The third is to find a way to sign the 1Password web client even as it is delivered over TLS.

    Adding to native clients

    The beauty of the web-client for us is that we can roll out features quickly in one place instead of having to develop and modify user interface elements in four different clients (Windows, Mac, Android, iOS). Quite simply, anything that requires a UI change in a native client takes a long time to develop and roll out. And so adding in admin console capabilities would be a slow process, for each platform.

    Packaging the web-client

    There are a number of technologies packaging up something like the web client into a signable download, but we need to find something what will be easy to maintain and deliver across platforms. In practice, our experiments with some of these have run into problems. Not insurmountable problems, but this turns out to be harder than one might initially expect.

    At this point, this is the approach that appears to be most promising, and is getting the most attention. But we will only know for sure when we actually have a working solution.

    Signing the existing web client

    The actual web client itself is delivered as a handful of files. We could look at publishing something like DSS signatures of those. The trick is for there to be tools within browsers that can check those signatures (and those signatures would have to have a trust chain that is separate from the site certificate trust chain.

    Although this is unlikely to be a usably secure mechanism to address the original problem, there may be other reasons for introducing something of this nature.

    Strengthening TLS

    One of the things that we are doing is working to reduce the possibility of attacks on TLS. We are quite strict about things, and make use of HSTS. Indeed, our use of HSTS has helped us learn that a number of business are intercepting their own TLS traffic to run their own "security" checks.

    Cloudflare

    You are correct that our (sometimes) use of CloudFlare presents another point of attack on TLS. And we do weigh this in our decision to use them. At the time I am writing this we are not using CloudFlare, but I cannot promise that that will be the case tomorrow. We have watch traffic patterns and see whether our more direct hosting works well enough.

    In conclusion

    The issues that you raise are real and thorny issues. But often the most obvious approaches to deal with them cause other problems. We are actively looking for workable approaches, but cannot promise exactly what we will do and when it will be done.

  • Thank you @jpgoldberg for the prompt and very transparent answer. I appreciate the challenges faced here; while I personally wish this would be an area where feature development would take a backseat, I understand that in the broader view having more users be willing to access web features is better than having them not using a password manager at all. But since the integrity of our digital lives depend on you, please hurry. :)

    I appreciate trying not to use Cloudflare when possible. I'm no expert, but certainly I can imagine the additional size of the attack surface that Cloudflare presents if web interface is substantially used.

  • brentybrenty

    AgileBits Team Member

    Indeed. And I really appreciated you starting this discussion, your comments here, and jpgoldberg 's response, which I think together encapsulate the challenge here nicely. Not everyone thinks about these things, and perhaps they rest easier for it. But we're willing to lose some sleep if we can continue to find ways to make 1Password even more resilient to attacks, both now and in the future. :blush:

Leave a Comment