Live data from Hacker News

1Password sends your password in clear text across the loopback interface

medium.com

101–110 of 147 posts

Re: 1Password sends your password in clear text across the loopback interface

#101

[Disclosure: I work for AgileBits, the makers of 1Password] We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-proces... This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine. For the most part, we do try to defend against something where we can. For example, we take steps…

> This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine.

It's likely that I'm misunderstanding things here, but here's what I'm imagining:

* I use 1Password and presume that my plaintext password stays on my machine.

* I use HTTPS for traffic that I care to secure.

* I contract to a vendor, with whom I don't share trusted information, to provide a dumb (non-VPS) shell, which I use for a variety of purposes.

* Among these, I use a SOCKS proxy to VPN traffic for some reason (say, to circumvent state censorship). Again, I presume that the vendor in question can't read my HTTPS traffic or 1Password info.

Can't the vendor in this case, who presumably has root on the machine in question, now sniff the loopback and find my passwords?

If the answer is "yes," then it breaks the workflow of trustless use of a SOCKS proxy.

Re: 1Password sends your password in clear text across the loopback interface

#102
post #69

[Disclosure: I work for AgileBits, the makers of 1Password] We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-proces... This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine. For the most part, we do try to defend against something where we can. For example, we take steps…

You can't just use some kind of Diffie–Hellman key exchange to agree on a key, instead of the user copying the key?

Are you suggesting simple DH without any long term secret?

Hmm. I'm fairly sure we thought through that option, but at moment I can't see see/recall why we rejected it.

Re: 1Password sends your password in clear text across the loopback interface

#103
post #29
post #14

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?

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

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.

Re: 1Password sends your password in clear text across the loopback interface

#104
post #82

If you can't trust your system, there is no point in encryption. There is an innumerable number of ways an attacker can get your password if you assume the attacker has system privileges. If you have loopback sniffing privileges, you could just also ReadProcessMemory the password right out of 1passwords memory.

If this was an easy task to tackle, we wouldn't be paying a commercial entity to take care of it.

You're not understanding. The only solution to this "problem" is to not give the computer access to the password, which defeats the purpose.

But the moment you trust the password to a compromised computer, it's game over.

Re: 1Password sends your password in clear text across the loopback interface

#105
post #69

Earlier quoted context omitted.

You can't just use some kind of Diffie–Hellman key exchange to agree on a key, instead of the user copying the key?

Are you suggesting simple DH without any long term secret? Hmm. I'm fairly sure we thought through that option, but at moment I can't see see/recall why we rejected it.

Well, unauthenticated DH ("simple DH without any long term secret") is trivially MITM-able, so it could only be useful if you adversary could read but not write to the channel, which I doubt is the case in this context.

Re: 1Password sends your password in clear text across the loopback interface

#106
post #46

Earlier quoted context omitted.

The author used `tcpdump -i lo0 -s 65535 -w info.pcap` which, as a non-root user without sudo, successfully captures loopback traffic in OS X 10.11.3. I just tried it, and with Chrome and 1Password, I was able to see my auto-filled bank password in the pcap. So, I presume any process on my system, without root privileges, would be able to sniff loopback. I don't see why 1Password wouldn't use TLS here. This is not go…

Your system is misconfigured. > $ tcpdump -i lo0 -s 65535 -w info.pcap tcpdump: lo0: You don't have permission to capture on that device ((cannot open BPF device) /dev/bpf0: Permission denied)

[deleted]

Re: 1Password sends your password in clear text across the loopback interface

#107
post #73

By no means an expert but is this even exploitable if the machine is not already otherwise compromised? Loopback is used for communication between two network applications on the same machine but it doesn't actually use the network device. Of course you'll be able to see it listening on your own computer but an outside computer can't sniff something that doesn't actually get transmitted over the network. Also in orde…

You're correct, the loopback works as you described. You should never see loopback packets anywhere but the host machine; if you do, that machine is compromised (not necessarily maliciously, but it's not working how it's supposed to be). I did a little poking around for a threat model for 1Password, but I couldn't find one. Plaintext over loopback is only a problem for 1Password if (and only if) 1Password was intendi…

You are correct that we are vague about the threat model in this case. But please keep in mind that encrypting local data at rest defends against a whole category of "compromise" (i.e., the data stored long term on the local disk being captured) then the case of a malicious process running on the user's machine while the user is actively using 1Password.

Officially our view is "if a malicious process with user privileges is running on the users machine when they use 1Password, there is little we can do".

But sometimes we try to do better. The example I raise is the steps we take to make things harder for keystroke loggers. We won't go to extraordinary measures to enter a battle that we can't win, but when there are simple things that we can do to make things harder for malware, we will.

See the first three paragraphs of https://blog.agilebits.com/2014/08/21/watch-what-you-type-1p... for some sort of attempt to clarify our vagueness about this threat model.

Re: 1Password sends your password in clear text across the loopback interface

#108
post #57

Earlier quoted context omitted.

Surely encryption with a shared key is strictly better than sending in plaintext? >In the extreme case, we could have some explicit pairing (sort of like Bluetooth) between 1Password mini and the extension. That is, the browser extension may display some number that you have to type into 1Password mini (or the other way around). With this user intervention we can provide solid mutual authentication, but that user act…

The browser would have to hold on to the shared key long term. Where does it put this? Encrypting with a key that is available to attackers (who have the same set a privileges needed to run localhost sniffing) is not encryption. It is obfuscation.

I thought the point of the arxiv paper was that a non privileged app could effectively "sniff" by pretending to be the other app.

If I'm understanding correctly, that means that encrypting with a shared key helps. Am I missing something?

Re: 1Password sends your password in clear text across the loopback interface

#109
post #101

[Disclosure: I work for AgileBits, the makers of 1Password] We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-proces... This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine. For the most part, we do try to defend against something where we can. For example, we take steps…

> This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine. It's likely that I'm misunderstanding things here, but here's what I'm imagining: * I use 1Password and presume that my plaintext password stays on my machine. * I use HTTPS for traffic that I care to secure. * I contract to a vendor, with whom I don't share trusted information, to provide a dum…

The vendor does not have root on your machine or access to the loopback interface. Your machine's loopback interface should not be exposed through a SOCKS proxy unless you specifically tell it to do so (which is a terrible idea for reasons beyond just this situation).

Re: 1Password sends your password in clear text across the loopback interface

#110
post #29
post #14

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?

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

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.

Post reply on HN