[jish]

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?

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

[LukaAl]

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

[pfg]

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.

[matthewmacleod]

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?

[jpgoldberg]

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.

[roustem]

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.

[jlgaddis]

They could at least encrypt it across the socket.

[euroclydon]

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