Authentication is not done by sending them your encryption password, but instead the derivation of an SRP static secret (https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...) from your password (PBKDF, XOR'd with HKDF of the entropy-boosting pepper that they call the "Secret Key"), and performing a session key exchange handshake, basically like a (non-ephemeral) Diffie Hellman. They then encrypt all future communications (inside of TLS) with the transient session key.
This gets you three things in one swoop:
- Authentication of user
- Authentication of the server (if the remote server doesn't have the stored RSA counterpart of your derived SRP static secret, the exchange can't complete)
- An additional encrypted tunnel independent of TLS, so transport security isn't reliant solely on TLS (Cloudbleed, etc). (The contents being moved around are encrypted yet again)
And:
- User doesn't have to remember a separate password.
- The password and pepper never touch the network, only (non-reversible) session tokens do.
- Having access to traffic inside of TLS (corporate or malicious TLS endpoint interception, for example) still gets you nothing.
There are valid criticisms of 1Password, but you're literally criticizing them for something they've gone out of the way explicitly spent engineering hours solving in a way that not many services have even bothered thinking about.
If you have gone through the process of being charitable-first, instead of dismissive-first, then you would notice that they have explicitly spent engineering hours on this exact problem by using an SRP-based session key exchange for mutual authentication (and additional session encryption, in addition to TLS). [1] [2]
It's not easy to engineer for both security and usability, so I especially appreciate it when someone spends the time to accomplish both.
[1] https://blog.agilebits.com/2015/11/11/how-1password-for-team... [2] https://1password.com/files/1Password%20for%20Teams%20White%...