21–30 of 147 posts
Serious question: Why is this a bad thing, and how would you do it differently? You need the password to be "plaintext" in the input field in the browser, so how do you get it there? Give the extension access to your private keys and master password to do decryption there? Is the browser a safer environment than an app on your machine?
Also in order to populate the password/credit card fields at some point doesn't the information need to be decrypted? I'd be more concerned if 1Password was storing the keys to decrypt passwords in a browser plugin as that is a way easier attack vector
Encrypted or not, if 1Password is sending passwords to the browser extension, that means its keychain is unlocked and malware, should it really want to grab data out of the keychain, could just request it from the 1Password helper itself. No need to passively sniff for passwords. I don't really see what the vulnerability is here.
That's the big issue, I think, unless I'm missing something.
Serious question: Why is this a bad thing, and how would you do it differently? You need the password to be "plaintext" in the input field in the browser, so how do you get it there? Give the extension access to your private keys and master password to do decryption there? Is the browser a safer environment than an app on your machine?
They could at least encrypt it across the socket.
At least on OSX 10.11 (not sure about others), you can't sniff loopback as a normal user. So, if you could sniff this, you'd have elevated privs anyway, which means you could read the keyboard device, memory, etc. Not ideal, but not sure it's a glaring hole. IMHO. I'd love to hear other thoughts on how to exploit this / how I'm underestimating this hole.
Serious question: Why is this a bad thing, and how would you do it differently? You need the password to be "plaintext" in the input field in the browser, so how do you get it there? Give the extension access to your private keys and master password to do decryption there? Is the browser a safer environment than an app on your machine?
As for the solution, without thinking too much, using TLS to encrypt the channel would do it. If we think the browser is not safe, well, all your stack is basically compromised. But if it could handle TLS correctly (and I guess it does it pretty well since it use it to send the info to your bank) it could get the password in a sfae way...
I'm not sure what the implications are. What has access to that information? Is it public to all services on the machine? Either way, I don't think this is 100% responsible disclosure.
Anyone with administrative access to the machine could run a capture on the loopback interface and gain access to the plain-text passwords. It's certainly an issue, albeit a limited one (the same user could sniff your keystrokes, etc.). The author gives his justification for full disclosure in the last paragraph. As I wrote yesterday [0], opinions vary regarding "responsible" disclosure -- and the "discoverer" gets t…