I would gravitate toward using a Unix domain socket, like what saslauthd uses.

I use saslauthd in a web server I wrote. I have the user ID and password from the browser over HTTPS, open a socket to /var/run/saslauthd/mux, and send them as plain strings, then check the reply.

The problem with loopback is that the only thing which prevents the program from sending the data to a rogue socket is the IP address and port number.

If I have some program binary which authenticates plain text passwords over an IP socket, I can probably find the "struct sockaddr_in" image of that address and change it to something else with a hex editor, to have that communication go to another machine. I'm not saying that this is the exact exploit; that would be a strawman: rather that there is potentially a very small code or configuration difference between a secure program that sends plain text over an IP socket, and a misbehaving one.) Of course, the path in a unix socket could also be tampered with; at least it won't go off box, though. The rogue piece listening to for the connection has to be planted on the same machine.

Unfortunately, there is no way for browser extensions to create Unix sockets,

Also, code signing would prevent anyone from modifying the binaries to change the IP address.

But even if they could, UNIX domain sockets aren't immune to attacks. That sort of the problem with "First, assume your machine has been pwn'd".

Yes; if we assume the machine has been pwned, then whatever we can still trust is anywhere else but in that machine. At best we can come up with ways to securely smuggle bits through the pwned machine between two trusted endpoints; but we cannot manipulate any secrets on that machine.

(Trusted computing relies on some tamper-resistant core of the machine not being pwned when the rest of it is pwned.)

Indeed, it would be particularly amazing if a browser extension did that on Windows. :)

I explained in a previous comment the problem.

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

You can't read loopback as a normal user. If you have root, you don't need to read unencrypted loopback traffic to get the passwords - just use a key logger.

Fair enough... or not!

First of all, when assessing security of a solution you have to define the perimeter of attack. You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger.

In other words, you are making an assumption that could be wrong!

Second, I could agree that perfect safety against every attack is impossible unless you assume your machine is switched off. But reasonable safety measure is achievable at low cost. Diffie and Hellman won the Turing price yesterday and their work is almost 40 years old...

> You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger.

That's a weird thing to say. If you manage to bypass file system access rules, there's any number of ways you can get access to the password manager.

I'm not convinced that any measure 1Password could take to make this harder would amount to more than mere obfuscation, with the cost of additional complexity (and attack surface).

That still means the password will be stored unencrypted in the browser's memory. AFAIK, this is no more secure than sending it unencrypted over the loopback interface; is there a scenario where one could snoop loopback, not not read browser memory?

yes, if the machine is reconfigured to allow loopback access for non-root users, they can sniff traffic but don't read arbitrary process memory. See discussion involving tptacek below, apparently Wireshark offers to make such changes, which might make it more common then one would expect initially (tons of devs have wireshark installed, and probably did that).

And where would the secret part of the TLS key be stored? As I've said before, encrypting with a key that is available to the attacker would merely be obfuscating. The only "value" of such obfuscation would be to conceal the security properties from the customer. It would make no difference to the attacker.

Obfuscation would mean that we wouldn't have to have this conversation as often as we do. But it would not make our customers more secure.

The problem is that in this case both the server and the client are the same machine. And if you have root access to it then you have access to everything including the private keys of the server.

They could at least encrypt it across the socket.

How is the encryption key supposed to get into the Browser plugin?

Same way as the encryption key used to secure the communication with your bank. It doesn't.

The idea behind TLS is that the client and the server agree on a temporary key to exchange the information in a secure way (there's a ton of literature on it) without saving the key locally. The good news is that it is something already implemented in a safe way in all sufficiently recent browser (for sufficiently recent I mean, sufficiently recent to support plugins, because also IE 6 supports some old form of SSL) and make them available to plugins.

TL;DR: It's trivial to do it right, screwing it up in this way means they have no clue on what security means.

In this case, client = server. If your computer is compromised then they can get access to both private and public keys of 1Password and 1Password Mini.

It also doesn't prevent MITM unless both the client & server. Nothing stops you from presenting a fake public key pair between the communication

How doe TLS work then? Because public keys are signed by central authorities. Who do we know what to trust? Browsers and OSes have default list of certificate authorities to trust. How do we know that we can trust them? Technically they should be communicated outside the internet. If the version of Chrome you download is compromised with a rogue certificate authority (ex: SuperFish) then you're hosed.

It's turtles all the way. Unless keys are communicated securely somehow you cannot guarantee secure communication.

Yeah, you should stop the turtle sequence. Maybe don't make it so easy that a script kid could exploit it, though...

How do you exploit it without already having root or sufficient capabilities to attack 1Password in other ways?