1Password security weakness?

Question

I was considering creating a 1Password families account because I liked the idea that 1Password never has the information needed to decrypt my passwords; however, when I created an account, I entered my master password on the 1Password website and then the website generated a PDF with my secret key.

If the 1Password website were somehow already compromised when I created an account, couldn't an attacker have the info they need from me now to decrypt my data, or am I missing something? It seems like it'd be better if some of this were done from a client-side app (assuming an attacker hadn't compromised that I suppose).

https://1password.com/files/1Password-White-Paper.pdf

Answer 1

Not only could 1password be hacked, they probably already have. Assuming that you have already been hacked is one of the cornerstones of modern security practice.

Even if their specific hackers haven't got access to their encryption keys, it is very likely that they'll just be voluntarily giving these keys away to a requesting government agency.

I'm something of an expert on secrets management, having designed and implemented secrets management systems for large banks. I strongly believe that if an external party has ever, even potentially, had access to a secret then it should be considered to have been disclosed, unsafe, and no longer a secret. Actually, I also believe that if a human ever has, even potentially, access to a secret, then it is also no longer considered to be secret.

Having said all that, the problem of 'initial trust' is difficult to solve. Generating an asymmetric key on your trusted device (say, your phone) and sharing one half of it with 1password to use as an encryption key while your device performs all the cryptography functions would be much safer, but would limit you to using your phone to interact with the service, and would depend on the strength of your phone's security (e.g. Samsung/Knox is the only trusted platform for most banks).

The current scheme allows government oversite and access by hackers and can not be trusted. But, it might be safer than your current scheme, so what to do with this info is still in your court.

Answer 2

If the 1Password website were somehow already compromised when I created an account, couldn't an attacker have the info they need from me now to decrypt my data, or am I missing something?

YES. And not only would you be vulnerable to this type of attack when you create your account – but, you would be vulnerable to this type of attack any time you login in to your account through 1Password’s web interface. This is because of the infamous browser crypto chicken-and-egg problem.

1Password acknowledges this. On Oct 29, 2021 I sent the following email to support@1password.com:

Hello 1Password Support,  I’m emailing you today with a question for your security team.

On your page at https://1password.com/security/, it reads, ‘Only you have access to your 1Password data’.  Also, your whitepaper at https://1password.com/files/1Password-White-Paper.pdf makes a similar claim on page 2, where it reads, ‘Server ignorance - We are never in the position of learning your Master Password or your cryptographic keys’.

However, with regard to 1Password’s web app, it would seem that if 1Password were to ‘go rogue’ (or if 1Password were to be coerced, or if an attacker were to gain access to 1Password’s servers, etc.), it would be possible for 1Password to modify the client-side code served by 1Password’s servers, such that the code captures the user’s master password or private keys, and sends these keys back to 1Password’s server (or somewhere else). As you may know, this problem was coined 'The Browser Crypto Chicken and Egg Problem' by security researcher Thomas Ptecek in 2011. In other words, if users can’t trust the server with their secrets, then how can users trust the server to serve secure crypto code?

I’m curious if 1Password has any comment on this subject. Specifically, if 1Password were to go rogue, would it be possible for 1Password to access users’ secrets by modifying the client-side code that you serve? If so, has 1Password considered any solutions to this problem?

1Password’s response was interesting:

Thank you for contacting us. While anything is possible to do, this would completely destroy our business overnight. Because of the size of 1Password and our commitment to being as secure as possible, we are audited regularly. If an attempt was made to add this functionality to our program it would be detected and disclosed. There also is no "switch" we could flip to allow such behavior as well. Well technically a patch could be released with this functionality, again this would be detected quickly.

As a password manager, our whole business model revolves around trust and security. breaking either of these would mean almost certain death of our company and almost certainly legal consequences. Again, while this "is possible" the likelihood of this happening is practically zero because of the checks and balances put in place.

Please let us know if you have any other questions.

As you can see, the representative acknowledges that such attack is technically possible, but cites legal and business reasons why it would not be in 1Password’s interests to ‘go rogue’.

But, the fact remains that users inherently do not trust 1Password's servers with their secrets.  This is why they use 1Password in the first place.  They rely on 1Password's "zero knowledge" solution to encrypt their secrets on the client side, so that these secrets never reach 1Password's servers.  Yet, ironically, these users rely on these same servers that they do not trust, to serve them secure crypto code that does the above.  It's the 'browser crypto chicken and egg problem' in action.

In fairness to 1Password, they are not the only service provider affected by this problem. Any provider that uses client-side crypto (or ‘in-browser crypto’) in a web application to build a 'zero-access' (or 'zero-knowledge') service is faced with this problem – and will continue to be faced with this problem until we have a viable solution to the 'browser crypto chicken and egg problem'. For some interesting reading on this problem, and some ideas around possible solutions, see:

Solution to the ‘Browser Crypto Chicken-and-Egg Problem’?

https://pageintegrity.net/

Answer 3

[Disclosure: I work for 1Password.]

If you use a malicious/compromised client, then all bets are off. And that would include a malicious web client. Unfortunately it is harder to protect the web client than the native clients. Native clients are codesigned and verified by the operating systems. Secondly, the delivery of a malicious web client can be very finely targeted and transient, thus making detection much harder.

We have been reducing the dependence on the web client, both by building more capabilities into the native clients and by releasing native clients for more clients. But this is a slow process, and I can’t promise a date when dependence on it will be eliminated.