If anyone is sniffing your loopback they can get any data passing between the two.
You have to be root to sniff network interfaces, and if you’re root you could just watch the keystrokes the user just typed in or do many other bad things.
There’s an interesting MITM attack that might be possible though that doesn’t require root privs. Basically you race 1pw to bind on the port it listens to, and if you get it then you get the user’s password when they type it.
This loopback traffic also appears to be specific to the use of the 1password browser plugins.
I personally do not use those, instead opting to manually copy/paste passwords out of 1password as needed (sometimes to non-browser locations too). I guess that likely leaves me vulnerable to pasteboard sniffers though.
EDIT: Looks like agilebits had a blog post about this a little while back.
Well, one place to dig further would be to look at the authentication between the two and see if other non-root processes could request passwords. I imagine the OS X application authenticates each client and will pop up the “enter your master password” prompt when a new client is requesting a login.
It’s certainly possible to imagine escalation of an exploit in another buggy extension, e.g. https://code.google.com/p/google-security-research/issues/detail?id=675
[Comment removed by author]
Ports have nothing to do with it, you have to open the bpf device to sniff traffic on any port on it, and that requires root.
The only way the port number matters is that since it’s >1024, non-root processes can bind to the port before 1password, so the communication would be going to the rogue process and not 1password, but that’s not sniffing and is possible with any listening process like that (which is why the important services are supposed to be < 1024).
Yes I deleted my comment after realizing that wasn’t the issue and that the MITM attack was the concern.
Honestly, if any malicious code ends up running on your system, let alone to the extent it’s sniffing network interfaces or is able to bind to an interface and setup a listening socket for a more complex MitM attack, you should reset any and every credential that your computer had access to, because at that point, you’ve been thoroughly compromised and need to assume the worst. Put simply: it’s not your computer any more.
Stopping to think about it, I don’t know of any password manager I’d be sufficiently confident with to use on a system that I didn’t completely trust, and that immediately excludes any system that I’m not the exclusive user of. So yes, this is sub-optimal from a defence-in-depth perspective, but at the point where this becomes a practical issue, it’s already over.
This title makes it seem like it’s your master password, but it seems it’s just the password for a particular site.
Yep—and that could also be stolen by any old browser extension anyway. This seems like a nonstory to me, but I guess it’s probably interesting for people who don’t think about attack vectors much.