Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

1Password 8 Early Access: Security, Comments, & FAQs

A few days ago, 1Password (my employer) released the first preview of the new application for macOS. The response has been rather dramatic. The release was followed by an excellent blog post by Michael Fey explaining the story of how we got here, and some of the decisions that were made in the process.

I’d like to now to a few minutes to answer some questions, provide some insight, and share my thoughts on this release.

This post does not reflect the opinion of anyone other than myself. I am not speaking on behalf of my employer, other employees, or anyone else. Nothing here references non-public information, nor will you find any commitments or concessions. Any errors are my own, and I apologize in advance for anything here that turns out to be incorrect. This article is provided in the hopes that it’ll help some gain understanding or insight.

Disagreeing Respectfully #

Before I continue, I would like to take a moment to comment on something I find both disappointing and disturbing. While there may be disagreements around decisions that have been made — what tech stack is used, what the app looks like, what features are or aren’t present — that doesn’t provide an excuse to be disrespectful to the people that worked hard to build this application. There’s no excuse for personal attacks.

The team at 1Password is amazing. They are deeply passionate about privacy and security (to a degree I’ve not seen anywhere else). They are warm & welcoming. They’ve built a culture where everyone is welcome just as they are. They care about users, and want to build the best software possible. While some disagree with the path taken, they are still humans, with feelings, and being disrespectful, rude, and attacking them simply isn’t appropriate. It isn’t right.

Please remember that when you’re talking to someone on social media, there’s a real person on the other side. Treat them how you would want to be treated. Be kind. It’s possible to disagree without being rude or resorting to personal attacks.

Questions & Answers #

I’ve been working to help address some of the questions coming up, and I’d like to collect some of these answers in one place. I hope this is valuable to you.

There are, of course, a lot of questions that I do not include here, as they’ve been answered elsewhere in sufficient detail.

Is storing my data on 1Password.com secure? #

Yes. All data is end-to-end encrypted, using a combination of your account password and Secret Key. The secret key contains 128-bits of entropy and is mixed with your password to create the value needed to log in, as well as the encryption key that protects your data. We never have access to your secret key, so there’s nothing we can do with your data.

If an attacker were able to get into the 1Password database, the data they get would be useless; as we don’t have the secret key, they wouldn’t be able to even attempt to brute force the key to access your data.

The security model is explained in detail in the white-paper (PDF).

Isn’t it unsafe to use Electron? #

It’s true that Electron is quite complex, as it’s built on Chromium - this creates a number of challenges for developers to use it securely. We’ve worked hard to take the proper steps to do it right.

We’ve done our due diligence to ensure that we are following all best practices, and reviewed issues found in other applications to ensure that we wouldn’t face the same problems. In addition, when possible, we work to eliminate entire classes of vulnerability instead of blocking specific vulnerabilities. This way, if new issues are found in the future, it’s less likely to impact us.

Some of the concrete steps that we’ve taken:

  • We’ve created and open-sourced a fork of the TypeScript Quick Start that our application is based on. This fork implements secure defaults based on a number of sources.
  • We’ve open-sourced the tool we use to modify the compiled binary to disable a variety of unsafe features, which prevents a number of security issues.
  • We use a strict Content Security Policy to prevent Cross-Site Scripting and other injection attacks.
  • We explicitly block the creation of WebViews and Windows, and never load content from the web.
  • No web requests are issued from Electron; any content that needs to be requested (such as favicons) is handled by the Rust Core.
  • All content is carefully sanitized, and our Markdown renderer is strongly-typed to ensure that there’s no possibility of it being abused (as an aside, we’ve built what I think is the most secure Markdown rendering system I’ve ever seen).
  • Node.JS integration is disabled, along with other features, which dramatically reduces the ability of an attack against the frontend from being to impact the system.
  • We closely monitor Electron for new issues, and keep the application on the latest version.
  • Most importantly, the Rust Core performs all cryptography, file system access, network access, and all the heavy lifting. This minimizes both the attack surface, and the ability of a successful attack impacting the frontend from being able to access sensitive data such as encryption keys.

While it’s impossible to eliminate every risk, the architecture used here has greatly reduced the risk of anything going wrong.

I should also note that in addition to our own efforts to secure the application, we conduct frequent third-party penetration tests of our applications. While we don’t publish penetration test reports for products or services that are still in initial development, this application has already been subjected to multiple penetration tests.

Should I stop updating if I don’t want v8? #

No, 1Password 8 will be a separate download, and will not be pushed to users of v7. Switching to v8 will be a decision you have to make yourself; we won’t make it for you.

In addition, we push important improvements and security fixes via the update mechanism. If you stop installing updates, you could miss out on updates that help keep you safe.

Why not use Tauri since you’re a Rust shop? #

We’ve been watching Tauri closely, and in fact, we are a Premium Sponsor providing financial support to help them mature. While we believe that Electron is the best option for the needs of this application at the moment, that could change as Tauri continues to improve.

We will continue to watch their progress closely, and have high hopes for their future.

Are you cutting costs or getting rid of developers? #

Far from it, development teams are bigger than they’ve ever been, and there are many open positions - including several new developer positions.

My internet connection isn’t stable, so I need my data to be local. #

When you are using 1Password.com (or 1Password.ca or 1Password.eu), the internet connection is used to sync your data, but it is still accessible even when you’re offline. Data is stored on your device, and changes will sync again once your connection is restored.

Having access to your data is critical, and the system is designed to ensure you can.

Why can’t I change the default keyboard shortcut? #

We know you’re used to the old one, and there will be the ability to change it in the future.

Please remember that this is the first preview release, meant for people who like the bleeding edge. It allows us to collect feedback, identify issues, and make sure we are building the right features. There are a number of things on the roadmap that aren’t in place yet.

What happens if my subscription expires? #

We don’t just start deleting data — it’s still there, and you can still get to it. But there are some things you can’t do until you renew your subscription.

How do I know you won’t just shut down, and I’ll lose my data? #

There are a few good things:

  • 1Password is a profitable company.
  • Raised $200M from investors in 2019.
  • Raised another $100M from investors in 2021.
  • Has great uptime.

Systems are reliable, data is backed up, and you can easily export it.

What about local vaults & standalone licenses? #

1Password co-founder Dave Teare covers this in a forum post. I’ll let his words speak for themselves.

I will point to one specific comment that’s quite important (at least to me):

We also had pushed standalone vaults (the underlying data format used by licenses) to their limit and couldn’t push them any further. Features like 2FA, secure remote password, account recovery, and many others weren’t feasible without connecting to a server to perform the heavy lifting.

There are issues that are challenging to solve with local vaults, and features that just can’t be added.

My Thoughts #

I’ve been happy to see how passionate users are about great software. I’ve been encouraged by the feedback we’ve received about new features being better than expected. I’ve been excited to hear from those that gave the application a fair chance. I’ve been disappointed by a vocal minority that resorted to personal attacks against my colleagues.

I’ve been using the new 1Password for Mac for some time, and I know what we can do with it in the future. I know what it’s capable of, and how good my own experience has been — and I’ve been a loyal 1Password user for a number of years. But speaking of what we can do in the future, I’m going back to working on building that future.

Adam Caudill


Related Posts

  • 1Password, PBKDF2, & Implementation Flaws

    …or “Crypto Is Hard, Vol. 479” Earlier today a tweet about a new feature for oclHashcat-plus started a truly interesting debate on Twitter over the implications. The new feature is the ability to crack 1Password keychain files – at an impressive 3 million passwords per second. Support added to crack 1Password to oclHashcat-plus, 100% computed on GPU! Plus I found an exploitable design flaw http://t.co/53ZtWggsDz — hashcat (@hashcat) April 16, 2013 To achieve this speed, two optimizations were used – the first is in precomputing ipad and opad for SHA1-HMAC, this effectively cuts the number of SHA1 calls in half.

  • Win by Building for Failure

    Systems fail; it doesn’t matter what the system is. Something will fail sooner or later. When you design a system, are you focused on the happy path, or are you building with the possibility of failure in mind? If you suffered a data breach tomorrow, what would the impact be? Does the system prevent loss by design, or does it just fall apart? Can you easily minimize loss and damage, or would an attacker have free rein once they get in?