[kazinator]

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.

[roustem]

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.

[julie78787]

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

[kazinator]

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

[kazinator]

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