1Password trying to upsell me on a cloud account

m4rkw

Hello

I use the standalone license on mac and iOS. While talking to support on a separate issue I had two rounds of strongly-motivated upselling on the cloud membership, offers of discount etc.

As far as I can tell this is a downgrade in terms of security. In order to log into the web interface I have to put all of the key material into a web form. This just seems like a really bad idea. I trust that AB are a reasonably sensible company and I think that trusting them is probably reasonable, but if I don't /have/ to trust them.. why do it?

If the website is compromised then all of the encrypted vaults are exposed - it would then be relatively simple for a motivated threat actor to steal the key material. This is not the case for the desktop or mobile apps, the application itself would have to be compromised which seems like a much harder thing to achieve.

Also OTP is a nice feature but it doesn't get included in the key material. With a standalone vault I can use a yubikey in static password mode to provide a huge blob of additional entropy to the master password.

I just don't see the point, it's more money for less security, but am open to being persuaded otherwise.

Mark

---

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

[Deleted User]

@m4rkw I understand your concern and it definitely feels safer to control where your database is stored. However, its not true to say that it would be a relatively straightforward exercise for an attacker to take all of the encrypted vaults at 1password.com and extract the key material.

Vaults stored at 1password.com are protected by your master password, unique secret key and the secure remote password protocol. The master password and unique secret key are required to derive each users master unlock key. Due to the secure remote password protocol these are never sent to 1Password's servers, even in hashed form. So the attacker cannot probe 1Password's servers to test master password/secret key combinations and would need to brute force each user's vault separately. This combined with 2FA means that your vault at 1password.com is at least as well protected as one at iCloud or Dropbox.

Taken together a 16-20 character master password and the secret key are likely to provide >200 bits of entropy, making brute forcing infeasible. However, there's nothing to stop you augmenting the master password with additional characters provided by the YubiKey's static password function.

There are additional risks when using 1Password in the browser to fill website logins, but to an extent this is an unavoidable part of logging in to accounts on the internet. The browser extension limits the risk in various ways, for example, by only revealing one login at a time, checking the URL before auto-filling and not allowing export or selection of multiple items.

However, all of this security requires the server and client software to be working as intended. I'm not an expert, but these security measures seem to me to be sufficient to ensure that the greatest risk is a software supply chain attack, whether using the browser extension or the desktop app.

DenalB

Hi @m4rkw !

1Password Membership is the way 1Password goes in the future! With the introduced version 8 it is not possible to use local vaults anymore. But you can use older versions as long as they work on your operating system.

For more information, please read here:
https://1password.community/discussion/121554/why-can-we-not-have-an-explicit-statement-about-1password-being-a-subscription-only-service

Lars

@m4rkw - thanks for dropping by and for the questions, and sorry about the confusion. The Customer Support folks you speak with when you email support@1password.com aren't salespeople and it's not their job to try to "upsell" you. However, with the recent release of the Early Access preview of 1Password 8 for Windows and the versions on other platforms to follow shortly, combined with the knowledge that 1Password 8 won’t include local vault support, those CS folks want to make sure people who write in know about the upcoming changes so they're not taken by surprise the first time they download the new version. The discounts are our way of saying "thanks" to all of you who have supported 1Password in the past.

I wanted to address a part of what you said:

If the website is compromised then all of the encrypted vaults are exposed - it would then be relatively simple for a motivated threat actor to steal the key material. This is not the case for the desktop or mobile apps, the application itself would have to be compromised which seems like a much harder thing to achieve.

First of all, these are some of the very considerations we went through when considering the design of 1password.com accounts. We knew we could do a lot more with them than we ever would be able to do with the constraints imposed by a local-only setup and multiple different sync options where we had to make do with 3rd party APIs since weren't the ones operating the servers (Dropbox, iCloud, etc). But we also knew that an "official" 1Password server containing millions of people's most-sensitive data would look like a prime target to some attackers, so we knew we had to make it even more secure than 1Password had already been as a standalone app without a server component.

Our solution for that was (as others here have already mentioned) something we call 2SKD (Two-Secret Key Derivation). In standalone (local vault) 1Password, your Master Password was what protected the 1Password data on your device. Even if an attacker stole your device and could get past your device passcode in some way, your 1Password data was encrypted -- and anyone trying to decrypt it would need your Master Password to do so. But because people create Master Passwords of varying length and strength, and we wanted to leave nothing to chance, we decided upon the Secret Key as the second secret in 2SKD, to make guessing your password computationally infeasible. The Secret Key is generated on your own device when you first sign up for a 1Password.com account, and it is never sent to our server in any form. It lives only on your own device(s). It's entire function, in fact, is to protect you in just the situation you envisioned: if WE get hacked. We take considerable server-side measures to make as certain as we can be that we are NOT hacked, but it would have been foolish to the point of irresponsibility to assume it could never happen.

Fortunately, with your Secret Key combined with your (hopefully long and strong) Master Password, your data is even more secure than it was in pre-membership 1Password. The Secret Key adds an additional 128-bits of entropy to whatever is provided by your chosen Master Password, making brute-force guessing essentially impossible in any reasonable timeframe. And because all en/decryption happens locally, on your 1Password app or browser before anything is sent to the server, the result is that we only have the encrypted form of your data, while never possessing the secrets with which to decrypt it.

In the scenario you envisioned, it's not the local application which would be compromised (the app itself is just code), it is the encrypted database of your 1Password data. Someone with access to your device would simply copy that encrypted database onto their own device, then run automated cracking attempts against it -- with your Master Password as the defense. Someone managing to evade all our server-side protections would also get an encrypted database containing your data...but now protected by not only your Master Password but also your 34-character, unguessable Secret Key as well.

Tertius3

If the website is compromised then all of the encrypted vaults are exposed - it would then be relatively simple for a motivated threat actor to steal the key material.

This is a wrong assumption. If some criminal gets your encrypted vaults from the 1Password cloud, he needs the same things as you to make them readable: the secret key and the master password. Both are used together to encrypt the vaults, and both are not saved by 1Password for validating your login. A hash of the master password is probably saved as hash for login, but the secret key never leaves your PC. On the 1Password website, there is no trace of your secret key. Decoding the vaults in the 1Password desktop app or browser app works by downloading the encrypted data and decode it locally with the locally stored secret key. This does not happen on the server.

Even if an attacker cracks your master password from a hash stolen from the website, it cannot decode the vault, because the secret key is still unknown. The attacker needs to steal it directly from your PC, and this is the same attack risk as with any locally stored standalone vault.

m4rkw

Hi Lars

Thanks for replying, I'm still confused by this though:

The Secret Key is generated on your own device when you first sign up for a 1Password.com account, and it is never sent to our server in any form. It lives only on your own device(s).

Someone managing to evade all our server-side protections would also get an encrypted database containing your data...but now protected by not only your Master Password but also your 34-character, unguessable Secret Key as well.

I understand this is the case, but you require me to enter both keys into a web form. If the web form were compromised an attacker could have it simply include both keys when making the initial login request to 1Password. The user wouldn't even be aware that their keys had been stolen, and since all the secrets are server side.. they'd have everything.

So given this, I struggle to see how having the second key really helps against this scenario.

Also the other scenario you mentioned, whereby an attacker compromises the database rather than the application, seems unlikely given the strong encryption present. By compromising the application I meant a supply chain attack, i.e. pushing out a backdoored version of the application that siphons credentials off somewhere.

In any case, since standalone vaults are going away, I have grudgingly relented and signed up. But I agree with others that I don't think the company has been entirely honest in the way it "let users decide". You made it very hard to even see that standalone licenses were available on the website for some time now, it's no surprise that the vast majority of people bought cloud licenses.

Mark

m4rkw

This is a wrong assumption.

Nah you just misunderstood me, sorry for not being entirely clear. See my reply for Lars for what I'm talking about.

m4rkw

Also for what it's worth, I would have happily paid a subscription to keep using the standalone vault. I guess I'm probably the minority though.

Tertius3

I understand now what you mean. This was discussed already somewhere in the forum, and as far as I remember there are blogs and kb articles about what 1Password does to protect the data against supply chain attacks and (mitm) website attacks. It boils down to design every module of 1Password that is talking to each other validates the other with cryptography.

I was convinced by that documentation that the 1Password cloud is secure enough for me, so I chose the subscription model. Since I want the convenience of sharing my vaults between multiple devices (its implementation is actually one main point of me choosing 1Password), there is no way around entering my 1Password credentials to the website from time to time. You have to be vigilant if you actually log in.

m4rkw

It boils down to design every module of 1Password that is talking to each other validates the other with cryptography.

I don't see how you can do that with a web form. All an attacker would need to do is make a web form that looks the same but posts the credentials to the server.

[Deleted User]

The master password and secret key are not stored server side. Neither are either of them sent in hashed form to the server. At account creation a long term verifier is generated server side using the secure remote password protocol. At every future attempt to connect the server confirms that the client has the master password/secret key and the client confirms that the server has the long term verifier. No secrets are exchanged in this process; instead they each solve a puzzle set by the other. As the puzzles are different each time, an attacker cannot use any of the information exchanged in a replay attack. And because the verifier is not used to encrypt the database it doesn't help an attacker to decrypt the database.

The other benefit of the secret key is that it increases the entropy of the key used to protect your database. Most users choose master passwords with around 80-100 bits of entropy, so an additional 128 bits makes a significant difference.

How is a supply chain attack on the webapp different to a supply chain attack on the desktop app? I appreciate that the browser is a more challenging environment, there are different vulnerabilities in the two cases and different techniques are required to mitigate them, but at the user level the two are very similar. Are you saying that a user is more likely to enter their secret key into a browser window than a desktop window? Or just that the former is more vulnerable?

m4rkw

How is a supply chain attack on the webapp different to a supply chain attack on the desktop app?

They're not /that/ different I suppose. I would just imagine that targeting the app would be harder because you'd have to not only engineer a backdoor in it but also get that pushed out via the various deployment channels, for iOS/Mac Appstore they'd have to go through app review.

Initial foothold viability aside, it would seem simpler to just inject some malicious javascript into the website and collect secret keys and master passwords. People keep saying it's never sent to the server and I understand that, but you're still typing it into a web form where the only thing standing in the way of it being sent to the server is the javascript code running in the browser.

Since what you've described here is a one-time cryptographic challenge, why not make that more plain to the user and have the 1Password app emit the solution to the one-time puzzle so we're not having to put the entirety of our key material into a web browser each time in order to log in?

Then my theoretical scenario of the website being compromised would be of far lesser impact.

Mark

[Deleted User]

Most of the code runs in the browser extension and only the necessary parts run in the page, so the browser's extension management takes the place of the app store, but I take your point.

The reason I keep banging on about the secret key is because, unlike the master password, you only need to enter it once per device. After that it is stored by the client application and used for secure remote password based verification. So users will not be expecting to enter it again and a webpage asking for it should raise red flags.

m4rkw

So users will not be expecting to enter it again and a webpage asking for it should raise red flags.

Maybe but I'm not convinced. If the 1password.com website showed the normal login form I think most users wouldn't think twice about continuing, especially since all the creds they need are conveniently stored in their local 1Password app.

[Deleted User]

But the browser will know it's a fake website and the 1Password browser extension will not offer to auto-fill. So making this work requires a supply chain attack which subverts the 1Password webapp or a man in the middle attack and cooperation of the user by copy/paste.

m4rkw

But the browser will know it's a fake website and the 1Password browser extension will not offer to auto-fill. So making this work requires a supply chain attack which subverts the 1Password webapp or a man in the middle attack and cooperation of the user by copy/paste.

Well yes, but compromise of the 1P website is the main threat scenario I've been talking about here and why I think there's a tangible difference between a standalone vault and the cloud service.

In order to steal the key material for a standalone vault you'd have to:

1) Gain access to 1P's environment
2) Gain access to the deployment pipeline for the app
3) Somehow without being noticed inject new code into a build of the app that then gets pushed out and signed as an update to users, again without being noticed, that steals the credentials and sends them back to either 1P or somewhere else

VS:

1) Compromise the website
2) Modify frontend JS to steal creds

This second scenario is way simpler than the first, it may even be possible with something as simple as an xss bug.

I don't think think either of these things is very likely to happen, but ultimately a motivated attacker really just has one target - the website. If that can be owned then the sky's the limit.

Mark

Ben

Hey @m4rkw

You are correct — this is a legitimate threat, and one we talk about in our white paper:

1Password Security Design White Paper

The relevant bit is appendix A — "Beware of the Leopard." We do of course have controls in place to help prevent such attacks but as you say if someone did somehow manage to replace the JavaScript that is delivered from our servers to your browser that would be a real problem. There are things you can do to mitigate this:

1. Sign up in-app using a desktop or mobile app instead of through the web app
2. Use 3rd party billing, as our direct billing can currently only be managed through the web app
3. Only use the web app when necessary — otherwise access your data through our other apps

For an individual user I believe it is possible to entirely avoid the web app if you sign up in-app and use 3rd party billing. This may vary depending on which platform you're on as unfortunately we don't yet have cross-platform consistency in terms of which administrative functions are available in the various apps. We are hoping to bring even more web app functions to the other apps to further mitigate the risk.

Ben

m4rkw

Thanks @ben, I will read it when time allows.

It sounds though like this is tacit acknowledgement that cloud accounts are more vulnerable than standalone vaults. I think it's a shame that a security company has ultimately chosen repeat revenue over user security but I guess that ship has sailed.

How about this as an improvement - if what @rootzero said is correct and that the master password and secret key are hashed into a time-based token for authentication, why not do this in the 1Password app instead? Have a button that says "Securely log into your account", when clicked it generates the OTP hash and bounces the user over to the browser with the token in order to log them in. Then we could log into our accounts without needing to type all of the key material into a web form.

Obviously you'd still need to leave the web form there for scenarios where the apps aren't available but it would at least makes the paranoid among us sleep a little better.

Lars

@m4rkw - sorry for misunderstanding your original question. As ben pointed out, Appendix A of our white paper (p. 52, "Beware of the Leopard") goes in detail through the potential risks that are introduced by using the web app. But I don't think that extends all the way to "acknowledgement that cloud accounts are more vulnerable than standalone vaults." I think a question worth asking in regard to that statement would be: vulnerable to what? While there's undoubtedly a difference in risk between running a server and simply not running one, it's worth pointing out that once 1password.com accounts became available at the end of 2015, the presence of Account Recovery for people who would otherwise be locked out of their own data permanently (which is an everpresent risk in standalone/local vault setups) and Travel Mode, which helps protect your data from prying eyes when traveling or other adversarial situations, represent substantial increases in both security/privacy and availability of users' data which would never have been achievable in standalone-only constructions. In other words, there are almost always advantages and disadvantages to any changes in method which touch on security or privacy; it is rarely as simple as "this option is more secure/private, this one is less."

In terms of the narrower point I think you were trying to make, on your local device(s), the stored cache of your encrypted data is as secure as it ever was (protected by your Master Password). Remotely, on our servers, it is protected by both the Master Password and your Secret Key, neither of which is ever transmitted to us.

The potential risks which are not present in standalone vaults are 1) limited, for the most part, to the use of the web app and 2) have available user mitigations that prevent or greatly minimize an already-small risk. Ben's already pointed out some of the most important of these, such as using 1Password apps exclusively; not only does doing so provide a better experience, it avoids most of the risks of using the web app.

But there are other mitigations as well, such as creating a specific browser profile you use for nothing except the 1Password web app (and no extensions in that profile), use this browser/profile only on trusted networks (like maybe a home desktop, not a mobile device), and manually checking certificates. I am a Family Organizer for my 1Password Families account (obviously, as well as being general IT support for the entire extended family, LOL), and my use of the web app is still quite limited. It extends to engaging Travel Mode (not common), account recovery (quite rare) and billing changes (even more rare). And my family use the web app even less than I do (the uncommon Travel Mode) -- because they don't have any need to. And on our (1Password's) side, using only the latest TLS versions (1.2 and 1.3), only strong cipher suites, HSTS, and safe JS constructions, help ensure there's as little chance of server-side mischief as possible.

I can't speak to what the future will hold with any kind of specificity, but bringing more of the administrative features present currently only in the 1Password web app into the local 1Password apps themselves is definitely part of future plans. At the risk of sounding mildly cheesy, "stay tuned" -- there's a lot more to come. We're very glad to have had the long-time support of early(er) adopters such as yourself back when 1Password was a standalone app, and we hope you'll stick around as we explore all the improvements that 1password.com accounts make possible, comfortable in the knowledge that our first priority is the security and privacy of our users' data.

m4rkw

Ben's already pointed out some of the most important of these, such as using 1Password apps exclusively; not only does doing so provide a better experience, it avoids most of the risks of using the web app.

Love it, “avoid the risks of this thing we built by.. not using it” xD

Ben

If you have further questions or concerns please feel free to reach out.

Ben