Is there anything about license/Dropbox that precludes secret key?

jbs · June 2018

I upgraded to 1PW7 mostly because I sign lots of clients up for 1PW (I'm an IT consultant) and I wanted to be able to show them a more accurate example of what they'd see when they use it. That said, about half my clients do prefer the license/Dropbox approach as opposed to monthly membership. I find the secret key approach very clever from a security perspective and I'm curious . . . is there a reason it only exists in the membership model? If not, is there any plan to implement it in the standalone license version? If I understand correctly, that would make the encrypted file on Dropbox significantly more secure in the case of someone accessing the Dropbox file. Again if I understand correctly today the local opvault file and/or Dropbox file are only as strong as the complexity of the master password whereas with the secret key then taking that file to a new device (where the secret key hasn't already been entered) makes the file MUCH harder to brute force. Am I understanding that correctly?

Thanks for all the work that went into v7. It looks and works great!

1Password Version: 7.0.558
Extension Version: Not Provided
OS Version: Win 7
Sync Type: Dropbox

AGAlumB · June 2018

@jbs: Great question, and I don't recall seeing it asked before. Typically we get questions about two-factor authentication, but of course local vaults have no server component for authentication. There are a few parts to this, so I'll try to break it down:

I find the secret key approach very clever from a security perspective and I'm curious . . . is there a reason it only exists in the membership model?

There are a lot of reasons, and I'll touch on all of the more below, but the short version is that the Secret Key (née Account Key) is something we've built into 1Password.com from the start because of the specific security properties we were looking for. So it's integrated in a way that just isn't possible with a 3rd party service which we don't control.

If not, is there any plan to implement it in the standalone license version?

This has a pretty straightforward answer: no. But I can go into more detail in a bit.

If I understand correctly, that would make the encrypted file on Dropbox significantly more secure in the case of someone accessing the Dropbox file. Again if I understand correctly today the local opvault file and/or Dropbox file are only as strong as the complexity of the master password whereas with the secret key then taking that file to a new device (where the secret key hasn't already been entered) makes the file MUCH harder to brute force. Am I understanding that correctly?

You're not wrong, but there are a few considerations here that we need to keep in mind:

Tech

It's probably possible to do something similar with local vaults, but it wouldn't really be the same under the hood. Local vaults are necessarily very self-contained, and there's no way for us to do the kind of integration with Dropbox (or anything else) that we can with both encryption and authentication with 1Password.com, since we built that service ourselves. They're just very different beasts, with significantly different use cases.

Compatibility

There are a lot of 3rd party tools that can work with OPVault (and AgileKeychain, though we're moving away from that in version 7), and the kind of changes that would be necessary to do something like this would break all of those. Any new format would also need to prove itself, as OPVault is already well-understood and time-tested. And, dare I say it, if we did this, a lot of people, rather than being glad we did, would view this as a means to force people to give us money to upgrade, in spite of...

The cost

We'd have to re-architect local vaults completely, and there just isn't a lot of demand there, or, frankly, revenue to justify doing that. If and when we see that OPVault's end is on the horizon, we'll have to do something at that time; but with the current state of technology that's probably a long way off. We'd also have to update all of the 1Password apps to work with it at great cost; and again, that would break backward compatibility with previous versions, which is more cost in terms of support and certainly some lost sales when people don't upgrade when it would break stuff in their existing setup for them.

Why?

There just isn't a good reason, honestly. With PBDKF2 calibration, we can increase the difficulty of the calculation as hardware gets more powerful, which in turn makes it exponentially harder on brute force attempts. A lot of people are also using local vaults because they're local, and doing a "Secret Key"-like thing would not benefit them; the purpose of the Secret Key is to make the data resilient to server breaches. Put another way, the Secret Key is there for us, since we're responsible for protecting people's data even in the case of a 1Password.com breach.

In the case of Dropbox, users can protect their accounts using two-factor authentication, strong passwords for their login credentials, and, if they want, use a random string not unlike a Secret Key as part of their Master Password. I know some people have been doing this for years using things like YubiKey. So, in practice, you can pretty much do this already.

What 1Password.com does is integrate the Secret Key right into the service itself, so it's used to both encrypt the data, authenticate with the server, and it's also presented all throughout our apps' design in a way that's user friendly (well, as much as is possible with a random, 128-bit string!)

There's simply no way to incorporate something like a Secret Key into the Dropbox authentication process, and adding it to local vaults optionally (not everyone would want this, after all) would cause even more confusion that what we've seen with 1Password.com over time and refined our design to make it easier.

I'm not sure if this is too much or too little compared for what you were looking for in a response, so be sure to let me know if you have any followup questions or comments. It's a really interesting topic, and I thank you for giving me the opportunity to riff on this a bit. :)