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