[grimborg]

Why is the 1password login the same as the encryption password for all my other passwords? There is absolutely no reason why I should ever send them my encryption password. If they would make these two passwords separate and handle all encryption/decryption locally, I think that would solve the issue for me.

[analogist]

Because they don't transmit your encryption password.

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.

[grimborg]

Thanks! I am so glad to see I was wrong on this!

[lowbloodsugar]

Indeed. This is so obvious that the fact that its not the case raises concern.

[analogist]

This is so obvious that the first thing I would do is look to see if they've addressed it in some way, instead of assuming incompetence.

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%...