[kentonv]

I am not affiliated with 1password, but I am a security engineer.

You are asking 1password to fix a non-issue. Sniffing loopback requires root privileges on the machine. If someone can sniff loopback, they can just as easily reach directly into the 1password processes's memory and extract the password from there, or replace 1password with a malicious extension that sends all your passwords to the attacker, or just log your keypresses. These other strategies may actually be easier than sniffing loopback. There is no reasonable defense against an attacker with root access, and encrypting communications over loopback would be a complete waste of effort and CPU time.

Honestly I feel bad for 1password that this article insinuating a security issue in their product is trending on HN when there is in fact no issue (as far as I can see, from the information presented).

[nullrouted]

It doesn't always require root privileges...for instance if some program (wireshark) changes the permissions on your loopback. There are other questions there but I'll probably dig into it later.

The thing I guess I would say bothers me about your post is you just say well, if a person gets access to a machine it is basically all over which isn't necessarily the case. Even if they get root access we don't want to make it easy, right? Thats why we encrypt databases or in certain cases storage at rest so even if the hacker has root access it is sure going to be hard.

1Password can never absolutely protect against an attack when an attacker has root. But they can make it harder then just dumping out lo0. Level of effort does account for something.

[kentonv]

> for instance if some program (wireshark) changes the permissions on your loopback.

That would be a serious security flaw in that program. Some program could also change the permissions on /dev/mem (or really any other device), with similarly disastrous results.

You can't expect 1password to defend you against other programs disabling the security of your operating system.

> if a person gets access to a machine it is basically all over which isn't necessarily the case.

Root access with ability to run sophisticated arbitrary code is game over, period.

Things that we should actually try to defend against (somewhat) include:

- A human briefly sitting down at your machine while you go to the bathroom. (E.g. Chrome's UI that allows you to display back your saved passwords in cleartext with no challenge is a legitimate security flaw, IMO.)

- Someone physically stealing your machine and then trying to dump the disk.

- Malicious software running without priviliges.

However, malicious software running as root is game over. Sorry, it is. Trying to make it hard for such software to do bad things is simply not feasible; there are far too many avenues of attack.

> Thats why we encrypt databases or in certain cases storage at rest

No, we encrypt data at rest to defend against physical theft of the storage medium, not to defend against live running processes that have root privileges.

If a malicious process has root, your encryption is meaningless. The key is in memory somewhere. The attacker doesn't really need to know where. They can dump the entirety of memory, and then cycle through it trying every N bytes as the encryption key and see if it works. This won't take very long!

[tangled_zans]

You make some very good points. Question is, is there any way to know if such a malicious program is on your machine?

[kentonv]

Maybe. Many will not hide themselves very well, but some use their power to make themselves invisible (often called a "rootkit"). I think the most promising approach to avoiding them is to use "secure boot" where the hardware verifies a signature on the firmware, which in turn verifies a signature on the OS, etc. ChromeOS devices (and some smartphones?) are pretty good at this. However, secure boot also prevents you, the rightful owner, from hacking (customizing) your own machine, which kind of sucks.