Who moved my cheese, 1Password?
Kenn White
18315

Kenn, thanks for writing this. As a 1PW cloud user who is an infosec enthusiast (and works in neuroscience! hi), I’ve also had that “queasy” feeling many times. I have quite a few thoughts and am very conflicted over this, but I have some points to add as someone who’s used the 1PW account model primarily and extensively:

In support of the cloud model in general:

  • Mobile-first is increasingly the model for any common user. Barring some sort of frictionless, universal, in-browser (above the “line of death”, not in-page) auth, easy synchronization of passwords across multiple device platforms is going to be necessary.
  • Mobile-first, especially iOS-first, is probably actually more secure for a lot of people.
  • “Cloud storage”, whether it be client-side encrypted and stuck inside Dropbox/iCloud/Google Drive, or through a centrally-controlled API like 1PW.com accounts, offers a good mobile-first experience.
  • While we’re already assuming people are going to be sticking the encrypted blobs in some sort of cloud for an average user, a centrally-controlled API is not *necessarily* less secure big-picture.
  • Sure, roll-your-own-blob-storage-API is certainly more vulnerable all else being equal compared to if the cloud storage part is abstracted away by a bigger company with a better security team, but you can also solve some attack vectors that plague users of more common cloud storage when you exclusively control the clients too: stolen devices; accidentally logged into Dropbox into someone else’s system; password reuse across your cloud storage, email, and the password manager, easy to crack passwords, sharing credentials with family without sharing your entire password manager, etc.

But I agree with you that I have plenty of queasiness about the specific implementation of the cloud storage:

  • Biggest problem I have, which has certainly been written about by you (and @tqbf https://twitter.com/tqbf/status/885566366585171968), is that you still need to use js-delivered pages to do many jobs, like account administration, adding users for Teams/Families, paying the bill, and changing access control for the “vaults”.
  • I asked about code-signed alternatives back before Cloudbleed (https://discussions.agilebits.com/discussion/75442/plan-in-the-works-for-account-administration-to-be-placed-inside-signed-executables) (when they were intermittently still using Cloudflare to deliver the js pages!). They’ve stopped using Cloudflare (that I know of) just before Cloudbleed occurred, but in general a break in TLS, or the web service, or any intermediate web services like between server and say, AWSELB, can easily mean all your credentials being stolen the next time you log into 1PW via browser. There hasn’t been any visible development from the customer side of a code-signed administrative option.
  • Removing credentials. This is another sore spot for me, because DELETING credentials takes a year (or 30 days if you pay for Teams). No, really. When you empty the “Trash”, credentials are purged from all native-code clients, but go into an “Archive”, accessible only via the web interface, ironically. https://support.1password.com/item-history/ There you can restore it up to a year, with no current implementation to purge this “Archive” on demand: https://discussions.agilebits.com/discussion/67453/how-to-purge-the-archive
  • The above is especially bad when doing credential sharing between Team/Family members. When you move items between “shared vaults” (an abstraction for credential store blobs with their symmetric keys encrypted by the user’s RSA-2048 key), the items are always “Archived” in the “vault” they moved from. The only workaround is to make a new vault and destroy the old one.
  • Destroying the “vault” doesn’t work with the one non-sharable vault that you start with (the “private” vault), so you have to destroy and re-enroll your whole account and move credentials over (via shared “vaults”) to truly purge a credential you don’t want to keep around. If you do defense-in-depth and use different accounts on different devices, this is especially painful.
  • As you mentioned, the Windows v6 client is 2nd-class. This is understandable in how new it is to the ecosystem (I don’t want to both complain about speed of development and care in developing it, that’s not fair), but things like local storage being introduced as read-only and then taken away is both alarming and not “easier to understand” for an end-user.
  • Things like “duplicate passwords” and “weak passwords” audit views are still not available in the Windows v6 client.
  • The entropy-boosting “secret key” on iOS is automatically saved into the iCloud keychain. I’ve complained about the lack of (https://discussions.agilebits.com/discussion/79580/remove-persistent-previous-accounts-on-ios-erase-all-data-should-actually-erase-all-data) implementation to remove them without, again, destroying and recreating an account.

That said, there are a lot of things I like about the specific implementation. Of course, I’m not app- or infosec anything other than being an enthusiast, but this is just my perspective:

  • Entropy boosting the password with the “secret key” so that effectively all derived keys “start with” 128 bits of entropy for non-local-file-system-compromise purposes is great (one might say necessary, if you’re going to make the system cloud-native). I guess it’s basically a 16-byte pepper. While other password managers have had this (Keepass calls it making a “composite key”), making it frictionless to the user is great. For example, this could help defend against things like shoulder surfing, or some abusive-relationship risks to the user.
  • The use of SRP (with the aforementioned pepper) to mutually authenticate with the server and to encrypt the session independent of TLS, and then finally inside this double-encrypted session having only encrypted blobs being ferried around (the keys for which cannot of course be derived back from the SRP), really sounds to me like a defense-in-depth design. To me this seems like it makes for a better transport layer for this specific application than, say, something that relies only on TLS and a persistent auth token like standard cloud storage providers. But please feel free to contradict, I’m no expert and maybe only just opens up the attack surface. From what I see, upside: you need a non-stored secret (the user password) to start the session, each time. Downside: deriving the SRP is expensive and so it’s stored and not as easily revokable as auth tokens.
  • (Of course, when using the browser, the entire above point is moot. I mean, it’s all implemented and you use it every time you use the browser, but the entire system of course makes-or-breaks on TLS.)
  • Being able to share credentials frictionlessly with family members is great — at least for me and many users. Really.

All of the above things, along with the fantastic job 1PW has traditionally done, keeps me on the 1PW subscription model, currently. I don’t know what the future has in store.

Like what you read? Give James Wu a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.