Why does getting a membership feel like a downgrade?

fabianfabian

I have been using 1Password for 8 years. I decided to get a membership because I did not want to use Dropbox anymore to sync between all my devices.

But instead of just a sync upgrade I got confronted with these downgrades:

1) Entering Master Password in the browser
I consider my browser insecure but in order to get a membership I had to enter my master password in the browser. Entering a password in a browser is always worse than not having to your password in the browser no matter how secure your sign up page is. This is a downgrade.

2) Where are my local back-ups?
Every few months I used to make a local back-up on a usb stick to keep in a different location. After switching to membership I no longer have this option. I can no longer have my own back-ups and I am now forced to rely on 1Password for back-ups? This is a downgrade.

I used to consider 1Password incredibly secure because of the way it mitigated against several attacks. If my Dropbox got compromised it doesn't matter because my vaults are encrypted with a master password. If 1Password servers got compromised, it doesn't matter because everything runs locally and does not rely on 1Password servers.

---

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

Ben

Hi @fabianfabian

I appreciate your concerns. I'd be happy to try and explain.

1) Entering Master Password in the browser

You're right. The browser can be a hostile environment. There are some ways you can help mitigate this. First, you can avoid this entirely if you sign up for an individual 1Password membership inside of 1Password for iOS or 1Password for Android and use Apple or Google for billing. We'd like to bring more of the web app's functionality (e.g. 1st party billing management) to the apps in the future so that it is more feasible for folks with other membership types or those who want to be billed directly can avoid the web app if they so desire.

Second, if avoiding the web app isn't possible (or desirable), there are some reasonable mitigations one can take to make the browsing environment more secure. We'd recommend extreme caution with any browser extensions installed in 1Password. If there are some you just can't live without, consider creating a separate browser profile without them for accessing the 1Password web app.

2) Where are my local back-ups?

This isn't currently available, but is something we'd like to be able to offer in the future. It is something that I personally am strongly advocating for, based on the level of interest in it. When we architected the 1Password membership service we decided that the server should be the "source of truth," rather than the clients. While this has proven to be the correct decision for a number of reasons, it does make restoring a local backup a tricky proposition (though not an unsolvable one, I hope).

As for what is currently available: the 1Password apps always work from a local database, which is then synced with 1Password.com when you're online. This database makes it such that if you (or we) are offline you can still access and modify your data. While this isn't designed to be a "backup," and I'd hesitate to describe it as one, having this database backed up is a reasonable precaution. Because the server is the source of truth the data in it may be overwritten by the server when you connect, but in an absolute worst case scenario you could disconnect from the internet, restore an earlier version of this database, and export your data.

Additionally it is possible to export your data (unencrypted). Again this isn't really a "backup" per se, as the purpose/intention with it is different. The idea with unencrypted exports is to make it feasible to move your data to a different password management solution if you so choose. That said, again, depending on your needs, this could potentially help as a stopgap until/unless more robust offline backups become a reality. We're also looking at adding encrypted exports, which may further this.

I used to consider 1Password incredibly secure because of the way it mitigated against several attacks. If my Dropbox got compromised it doesn't matter because my vaults are encrypted with a master password. If 1Password servers got compromised, it doesn't matter because everything runs locally and does not rely on 1Password servers.

1Password always encrypts your data before saving it to the local database, which happens prior to sync. Your Master Password protects the 1Password data on your computer. With membership, we've added an additional layer of security. Your data is also protected by the Secret Key, and this is the most important protection for the data stored on our servers. You can read more about the Secret Key here:

About your Secret Key

The long and short of it is that it prevents the data on our servers from being valuable. Even if someone were able to dump our entire database it would be infeasible for them to break everyone's individual Secret Keys.

Thank you for your long-time use of 1Password. I hope that helps address your concerns. If there is anything else, please let us know.

Ben

fabianfabian

I appreciate the response, thanks for explaining.

I suppose the secret key helps, if it is only used locally within the application, but it does not defend against a compromise of 1Password servers because the secret key is requested in the browser (https://my.1password.eu/signin).

I hope the encrypted export will be added. My use case is an emergency situation where if something goes wrong in the cloud (this was Dropbox before, and is 1Password now) then I still have make local recovery that does not rely on any service provider.

Jack.P_1P

Hi @fabianfabian:

In this case, it feels counterintuitive, but in this case, the Secret Key isn't being sent to the server. my.1password.com (or .ca/.eu) is a web app running inside your browser, and the decryption is not happening on our servers, but instead happening locally on your computer. Our servers never receive your Secret Key or your Master Password as part of the decryption process (and neither do they receive it when they are created, because all of that also happens locally).

The math behind this is the Secure Remote Protocol, if you'd like to learn more, our security white paper talks about the math, in the section SRP starting on page 76.

Jack

fabianfabian

I understand the security model, the secret entered in the browser is not sent because you made the assumption that my browser is secure and your webserver has not been compromised. While this would be a reasonable assumption for the average webshop or service, I feel it is unacceptable to protect a lifetime of passwords.

ag_ana

@fabianfabian:

I understand the security model, the secret entered in the browser is not sent because you made the assumption that my browser is secure and your webserver has not been compromised.

The idea is actually different. From our documentation:

Your Secret Key protects your data off your devices. Someone who attempts a brute-force attack on our servers won’t be able to decrypt your data without your Secret Key, which we never have.

So the Secret Key actually helps in case our server is compromised.

fabianfabian

So the Secret Key actually helps in case our server is compromised.

This is why I had no problem hosting my vaults on Dropbox. I assume Dropbox is comprised, just as I assume your vault servers are compromised, and I still know I am safe because of the secret key, which has never left my device, because the only location I ever entered it was in the 1Password application. This changed the moment I had to enter (or receive) the secret in the browser.

It is magnitudes harder to compromise the application software than it is to compromise a sign-up or login page, which relies not only on the security on your side but also on the browser and extensions.

Ben actually understood and partially addressed this concern and now it is weird that I have to explain it you.

My concern is entering in the browser is not secure, when I enter or receive the secret key in the browser I should consider it leaked. I never had to enter any secret key or master password in a browser before in the last 8 years using 1Password, this was great.

You say in case your (vault) server is compromised it is protected by the secret key, I say I already consider your server compromised and my only protection is the secret key, which is now touched by a browser in the downgraded security model.

ag_ana

@fabianfabian:

Ben actually understood and partially addressed this concern and now it is weird that I have to explain it you.

Thank you, but no need to explain it again, I perfectly understand your concern :)

I assume Dropbox is comprised, just as I assume your vault servers are compromised, and I still know I am safe because of the secret key, which has never left my device

That's exactly it: the Secret Key does not leave your device, even if you are entering it in the browser, because you are entering it in a local application running inside the browser, but still on your device. This is where the confusion comes from I think.

Of course, in case you enter information on a compromised website instead, it's an entirely different topic. But even if, as you say, "it is magnitudes harder to compromise the application software than it is to compromise a sign-up or login page", this is a moot point in case your device itself is compromised, for example with a keylogger.

You say in case your (vault) server is compromised it is protected by the secret key, I say I already consider your server compromised and my only protection is the secret key, which is now touched by a browser in the downgraded security model.

The Secret Key is not your only protection: it's the combination of Secret Key and Master Password that protects your data. The Master Password is not sent to us either, so while they both protect you against different scenarios, they also work together so you don't have to rely on a single protection (the Master Password in case your data is hosted on Dropbox).

I hope this clarifies things :)

fabianfabian

That's exactly it: the Secret Key does not leave your device, even if you are entering it in the browser, because you are entering it in a local application running inside the browser, but still on your device. This is where the confusion comes from I think.

The confusion is because we have a different assumption, you assume the browser is secure and is able to keep the secret local, I assume my browser is not secure and will alter your sign-up page to send the keys somewhere else (both keys since they are entered on the same page). You also seem to assume that OS level security is on the same level as browser security.

[Deleted User]

@fabianfabian I understand your concern, but I would phrase it differently. The security provided by the combination of the account password, secret key, secure remote password protocol and two factor authentication is such that the main risk becomes being served compromised software.

When using the webapp, your browser is served software on the fly and there are more opportunities for it to be compromised. When using an app on your device, the software is better protected, it is downloaded less often and there are more robust means of checking that it is legitimate.

For these reasons, I use the desktop to do anything that can be achieved in the desktop app. For those few things that require the webapp, I use a dedicated browser profile with no extensions, the login page saved as a bookmark, cookies cleared on exit and a hardware security key as two factor authentication.

ag_ana

@rootzero:

For these reasons, I use the desktop to do anything that can be achieved in the desktop app.

Same here actually: I don't remember the last time that I logged into the web app to do something (probably the last time we invited a family member to the account). I think overall you need the web app just in very limited cases.

masonke

I can see a major problem here. If either the copy of a vault on the one password servers, or the copy on the clients disk is hacked, both will be compromised on the next sync. How do we recover from that without backups?

soshiito

If either the copy of a vault on the one password servers, or the copy on the clients disk is hacked, both will be compromised on the next sync.

True regardless of what server is doing the syncing: 1Password or Dropbox, it makes no difference here.

How do we recover from that without backups?

Nobody said you can't back up the data that is on your computer and restore from those backups. This was covered above:

As for what is currently available: the 1Password apps always work from a local database, which is then synced with 1Password.com when you're online. This database makes it such that if you (or we) are offline you can still access and modify your data. While this isn't designed to be a "backup," and I'd hesitate to describe it as one, having this database backed up is a reasonable precaution. Because the server is the source of truth the data in it may be overwritten by the server when you connect, but in an absolute worst case scenario you could disconnect from the internet, restore an earlier version of this database, and export your data.

What is described here is a worst case scenario, which the one you outlined would be. Backups do not undo your credentials being compromised.

ag_ana

Correct! And alternatively, as Ben also mentioned, it is always possible to export the data to have an additional copy stored somewhere else:

How to export data from 1Password