121–130 of 147 posts
Earlier quoted context omitted.
Yeah, it's that they installed Wireshark, and gave it privileges to chown the loopback interfaces. edit: Irony here is that Wireshark is doing something far more dangerous than 1password.
It's either a) change the group on the /dev/bpf entries and add your user to that group or b) run Wireshark as root.
In february 2015 I had contact with agilebits at support@agilebits.com and they answered me within a day. Seriously, you claim you tried to reach them, but I have a hard time believing that. What is 'not too long ago'?
Earlier quoted context omitted.
It's either a) change the group on the /dev/bpf entries and add your user to that group or b) run Wireshark as root.
b) would in general be a lot safer, in that you're elevating one process rather than lowering a privileged interface so that every process you run can sniff it.
What's been done here by Wireshark isn't least privilege, or secure. Its like the opposite of least privilege and security.
Earlier quoted context omitted.
Particularly if someone is specifically targeting 1password, which they (almost by definition) already would be. It'd just be a single patch to the exploit and you're back in business. Well, okay, obviously that's an oversimplification, but it wouldn't do you much good regardless.
But then malware must run as root.
General question: why is it so common to use loopback, vs unix domain sockets? I haven't seen the latter used outside of mail infrastructure, and they seem slightly more secure to me regarding who can connect to them.
Two reasons we don't use unix domain sockets are: 1) they are not cross platform 2) they can't be created by browser extensions
[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…
Author here: Thank you for responding. The reason I wrote this up is not to let people oh my god the world is ending but to let them know, hey if you are using the browser extension there is clear text passwords being sent over the loopback, if you don't like that then don't use their extensions. You have made very well informed arguments about how hard it is to protect if someone has access to your machine, specific…
If you only want to pair it once then you will need to store the pairing secrets somewhere. Since both server and the client are running on the same machine, it is going to be trivial to obtain this information.
Re: other password managers did something. It must have something to do with the disdain for obfuscation that we had for a long time. Encryption is good, obfuscation is a lie. We always felt if we obfuscate something then we will be lying to everyone. I am not blaming anyone and concede that our position might be a bit naive in this case.
Earlier quoted context omitted.
I would gravitate toward using a Unix domain socket, like what saslauthd uses. I use saslauthd in a web server I wrote. I have the user ID and password from the browser over HTTPS, open a socket to /var/run/saslauthd/mux, and send them as plain strings, then check the reply. The problem with loopback is that the only thing which prevents the program from sending the data to a rogue socket is the IP address and port n…
Unfortunately, there is no way for browser extensions to create Unix sockets, Also, code signing would prevent anyone from modifying the binaries to change the IP address.
[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…
Author here: Thank you for responding. The reason I wrote this up is not to let people oh my god the world is ending but to let them know, hey if you are using the browser extension there is clear text passwords being sent over the loopback, if you don't like that then don't use their extensions. You have made very well informed arguments about how hard it is to protect if someone has access to your machine, specific…
I really really don't like talking about how our competitors might do things. (I work for AgileBits, the makers of 1Password). But I can talk about why we picked one security design over a plausible alternative. So here goes.
One way such a system could work is that the browser extension could talk to a process on the provider’s server. Because the server is remote, the TLS secret key would be stored on that remote server, and so would not be accessible to a root process running on the user’s system. This would, indeed, solve the IPC issue as there wouldn’t be any IPC.
There are a few reasons why we don’t operate that way. To operate that we we would end up knowing when and where our customers log into things. But we don’t want to be in a position to learn our customer’s shopping habits or whether they log into ISecretlyLoveNickelback.org. But with the client server model of that way of doing such things, we would be getting lots of that kind of information and holding on to some of it unencrypted.
Similarly, we don’t want to store any information that if stolen from us would enable such a thief to try to make cracking attempts at people’s Master Passwords. Sure PBKDF2 is good, but it only provides temporary protection should the data be stolen. We also don’t want “big” secrets in the browser. Our browser extension never sees your Master Password and only ever has the password for site it is filling for (or learning from). We see the browser as a very hostile environment.
Now there are certain ways around some of those things. And again, I’m not making any claim about how any other product does things. I’m only discussing how a service with the properties you describe might work.
Different security designs expose different sorts of threats. Nobody can really defend against an attacker running as root on their own system, but our more obvious exposure to to running on a rooted machine in this particular scenario is something that we think is worth the security and privacy benefits of our design.
[Note: I have plagiarized myself from https://medium.com/@jpgoldberg/ross-regarding-your-makes-you... as I'm being asked the same questions in different locations]
[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…
Author here: Thank you for responding. The reason I wrote this up is not to let people oh my god the world is ending but to let them know, hey if you are using the browser extension there is clear text passwords being sent over the loopback, if you don't like that then don't use their extensions. You have made very well informed arguments about how hard it is to protect if someone has access to your machine, specific…
To pair it once would mean that a long term secret would need to be stored. Now we consider ourselves experts at storing long term secrets, but this one would need to be available to 1Password Mini and/or the browser extension even when 1Password is locked. So it would need to be stored on the local machine in a way that is not protected by 1Password.
So an attacker with root privileges (as needed for the loopback sniffing) would be able to get that key. And as I've said in various places throughout this conversation, "encrypting" something with a key that is available to the attacker is merely obfuscation.
Earlier quoted context omitted.
Sending in plaintext is sloppy. You can have any protocol over loopback.
And where would you store the keys for that communication in a way that an attacker with root privileges couldn't get it? "Encrypting" with keys available to the attacker is mere obfuscation. In this case, it would provide no extra security to customers; all it would do is lead them to believe that something is encrypted when it is merely obfuscated.
If they are hard-coded in the binary, they can be extracted off-line by another use with the same binary. If they are generated at run-time, they have to be stored with permissions that grants the user access to their own resource.
There are programming techniques for sharing a file descriptor, but they aren't portable. That makes generating a keypair, then sharing an open file descriptor to the file containing the keypair impossible.