Protection from bad URL?
I accidentally entered "op signin example.1pasword.com username@example.com" instead of "example.1password.com" (note typosquatter domain).
I was unable to log in, and when I try to access "1pasword.com" in a web browser, the proxy/malware scanner where I work filters the page and denies access as "malicious site" so I'm hopeful nothing bad happened.
Additionally the tool gave an error message rather than connecting successfully:
[LOG] 2018/09/14 15:22:27 (ERROR) Get https://EXAMPLE.1pasword.com/api/v2/auth/EXAMPLE@EXAMPLE.com/XX/HASHY/HASHHASHHASH: dial tcp XXX.XX.XXX.XXX:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Does the command-line tool protect against doing something bad here by checking the server certificate or something? If not did I luck out with my work proxy or something? Or did I just send my master password and secret key to bad guys? I really don't want to go through and change every password in every vault in my family account, revoke all the secret keys, and memorize a new master password, this weekend. :(
1Password Version: CLI 0.5.3
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: Not Provided
Comments
-
I went ahead and changed my own secret key just in case. But if my master password actually made it off my system I'll want to change that also so do please let me know either way. I'm the family administrator so someone with my login could do a lot of damage. I did not see any suspicious "Authorized Devices" listed so I think that means nobody took advantage of my mistake yet (even if it's possible).
0 -
@fritzophrenic: Indeed, sorry for the scare! The error indicates that the server wasn't even listening, and if they had been would have failed the TLS handshake anyway. And that's just the start of the good news! ;)
I can't speak to the specifics regarding what the CLI app checks so @cohix or @rickfillion may jump in here, but with 1Password accounts, no matter what, we're never sending account credentials, period. The server won't even accept them, as we're using SRP to ensure that no secrets are exposed (since they're not sent in the first place, only a cryptographic verifier) even in the case of a person-in-the-middle attack or TLS failure.
So you definitely don't need to worry about your credentials being exposed. Since we absolutely don't ever want to have them (and the server will not accept them), we've setup the 1Password account protocol not to use them at all. So if anything had been successfully sent to the impostor's address, it would still be complete gibberish to them, and they would not have the means to un-gibber-ify(?) it. And again, your account credentials are simply never included in the payload. So rest easy. :)
0 -
Now, THAT is a cool algorithm! Thanks for demonstrating why I picked you guys in the first place. It's little things like this, finding ways to never have my password even briefly for authentication, that set 1password apart!
It looks like there are plenty of docs online to read more about SRP so I know one thing I'm doing today. :) Most of the write-up you linked is pretty clear but I'm not quite sure about the role of the verifier generated during enrollment or how it would be used in future sessions with multiple devices.
But that's just me nerding out on security stuff. Thanks for putting my mind at ease!
0 -
Incidentally...this story had a happy ending, but is there any chance you guys would consider registering 1pasword.com in the future? Those kinds of squatters just make me mad.
0 -
This also gives me a real life example to use when next writing about the benefits of SRP's mutual authentication and zero-knowledge, so a doubly happy ending.
We have registered a bunch of squattable domains, but someone beat us to this one. The difficulty that we face in trying to acquire it from whoever has it is that doing so incentivizes domain squatting. It is a lot like paying ransom.
0
