71–80 of 147 posts
Earlier quoted context omitted.
This is a fresh OS X install on a test machine :/
Works for me too on OS X. sudo is not needed to run tcpdump for any interfaces. $ ls -l /dev/bpf* crw-rw---- 1 root access_bpf 23, 0 Mar 1 09:18 /dev/bpf0 Edit: Wireshark is installed
Later
Yes. Your system is misconfigured. Don't let Wireshark do that.
Earlier quoted context omitted.
How is the encryption key supposed to get into the Browser plugin?
Same way as the encryption key used to secure the communication with your bank. It doesn't. The idea behind TLS is that the client and the server agree on a temporary key to exchange the information in a secure way (there's a ton of literature on it) without saving the key locally. The good news is that it is something already implemented in a safe way in all sufficiently recent browser (for sufficiently recent I mea…
It also doesn't prevent MITM unless both the client & server. Nothing stops you from presenting a fake public key pair between the communication
How doe TLS work then? Because public keys are signed by central authorities. Who do we know what to trust? Browsers and OSes have default list of certificate authorities to trust. How do we know that we can trust them? Technically they should be communicated outside the internet. If the version of Chrome you download is compromised with a rogue certificate authority (ex: SuperFish) then you're hosed.
It's turtles all the way. Unless keys are communicated securely somehow you cannot guarantee secure communication.
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…
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 intending to protect against machine compromise. Now, it's a little difficult to decide if that's the case, since they are encrypting everything locally, explicitly to protect against machine compromise, but is that compromise in case of eg. machine confiscation, or compromise in case of eg. local malware?
Presumably, 1Password isn't trying to address the latter case (and I haven't heard them say otherwise). And to be honest, I'm extremely skeptical that protecting against machine compromise is something you can do at anything other than an operating system level, especially for anything involving IPC (like 1Password).
Edit: I'll defer to jpgoldberg's comment above. [1] They've made a risk/benefit analysis decision on handling IPC that it's too difficult to secure, and that effectively any security for the IPC to browser would be 1) functionally meaningless to a targeted attack, like obfuscation, or 2) present undue burden to the people using the software. I'll +1 their analysis (they also have several blog posts on the topic); makes sense to me. “Once an attacker has broken into your computer, it is no longer your computer.”
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)
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)
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…
Not if the shared key is present in the host computer already, which it'd have to be if the host process is to decrypt anything.
That is obviously sloppy work on the part of the developers. And bad. But anyone that can snoop on loopback already owns the machine and he could just cheat engine the passwords from the browser ram. So it is not making safe situation bad, but bad situation worse. Of course with Blizzard Warden, Steam anti cheat, driver level firewalls and all the other little helpers that collect information about your system - this…
I have a problem with the phrase "obviously sloppy work on the part of the developers." How exactly does one avoid loopback in an application like this? Your second point is spot on though I think, one would need to own the machine already before being able to sniff loopback.
[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…
Earlier quoted context omitted.
In a corporate environment, a system administrator with administrative access to employee/user machines could gain access to their credentials. That's the big issue, I think, unless I'm missing something.
They can do that anyways by sniffing the keyboard directly.
Earlier quoted context omitted.
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...
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?
Earlier quoted context omitted.
In a corporate environment, a system administrator with administrative access to employee/user machines could gain access to their credentials. That's the big issue, I think, unless I'm missing something.
Someone with administrative access would have an almost unlimited number of ways of accessing passwords in any password manager. Key logging, memory dumps ... once your system is owned, you're SOL.