5 ms·

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 h

by jish 11y ago

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?

deleted 11y ago
[deleted]
jlgaddis 11y ago
They could at least encrypt it across the socket.
- euroclydon 11y ago
  How is the encryption key supposed to get into the Browser plugin?
  - LukaAl 11y ago
    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 mean, sufficiently recent to support plugins, because also IE 6 supports some old form of SSL) and make them available to plugins. TL;DR: It's trivial to do it right, screwing it up in this way means they have no clue on what security means.
    - jeeyoungk 11y ago
      In this case, client = server. If your computer is compromised then they can get access to both private and public keys of 1Password and 1Password Mini. 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.
      - LukaAl 11y ago
        Yeah, you should stop the turtle sequence. Maybe don't make it so easy that a script kid could exploit it, though...
        cyphar 11y ago
        How do you exploit it without already having root or sufficient capabilities to attack 1Password in other ways?
LukaAl 11y ago
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...
- pfg 11y ago
  You can't read loopback as a normal user. If you have root, you don't need to read unencrypted loopback traffic to get the passwords - just use a key logger.
  - LukaAl 11y ago
    Fair enough... or not! First of all, when assessing security of a solution you have to define the perimeter of attack. You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger. In other words, you are making an assumption that could be wrong! Second, I could agree that perfect safety against every attack is impossible unless you assume your machine is switched off. But reasonable safety measure is achievable at low cost. Diffie and Hellman won the Turing price yesterday and their work is almost 40 years old...
    - pfg 11y ago
      > You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger. That's a weird thing to say. If you manage to bypass file system access rules, there's any number of ways you can get access to the password manager. I'm not convinced that any measure 1Password could take to make this harder would amount to more than mere obfuscation, with the cost of additional complexity (and attack surface).
- matthewmacleod 11y ago
  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?
kazinator 11y ago
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 number. If I have some program binary which authenticates plain text passwords over an IP socket, I can probably find the "struct sockaddr_in" image of that address and change it to something else with a hex editor, to have that communication go to another machine. I'm not saying that this is the exact exploit; that would be a strawman: rather that there is potentially a very small code or configuration difference between a secure program that sends plain text over an IP socket, and a misbehaving one.) Of course, the path in a unix socket could also be tampered with; at least it won't go off box, though. The rogue piece listening to for the connection has to be planted on the same machine.
- roustem 11y ago
  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.
  - kazinator 11y ago
    Indeed, it would be particularly amazing if a browser extension did that on Windows. :)
  - julie78787 11y ago
    But even if they could, UNIX domain sockets aren't immune to attacks. That sort of the problem with "First, assume your machine has been pwn'd".
    - kazinator 11y ago
      Yes; if we assume the machine has been pwned, then whatever we can still trust is anywhere else but in that machine. At best we can come up with ways to securely smuggle bits through the pwned machine between two trusted endpoints; but we cannot manipulate any secrets on that machine. (Trusted computing relies on some tamper-resistant core of the machine not being pwned when the rest of it is pwned.)

by jish 11y ago

deleted 11y ago

[deleted]

jlgaddis 11y ago

They could at least encrypt it across the socket.

euroclydon 11y ago
How is the encryption key supposed to get into the Browser plugin?
- LukaAl 11y ago
  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 mean, sufficiently recent to support plugins, because also IE 6 supports some old form of SSL) and make them available to plugins. TL;DR: It's trivial to do it right, screwing it up in this way means they have no clue on what security means.
  - jeeyoungk 11y ago
    In this case, client = server. If your computer is compromised then they can get access to both private and public keys of 1Password and 1Password Mini. 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.
    - LukaAl 11y ago
      Yeah, you should stop the turtle sequence. Maybe don't make it so easy that a script kid could exploit it, though...
      - cyphar 11y ago
        How do you exploit it without already having root or sufficient capabilities to attack 1Password in other ways?

LukaAl 11y ago

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

pfg 11y ago
You can't read loopback as a normal user. If you have root, you don't need to read unencrypted loopback traffic to get the passwords - just use a key logger.
- LukaAl 11y ago
  Fair enough... or not! First of all, when assessing security of a solution you have to define the perimeter of attack. You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger. In other words, you are making an assumption that could be wrong! Second, I could agree that perfect safety against every attack is impossible unless you assume your machine is switched off. But reasonable safety measure is achievable at low cost. Diffie and Hellman won the Turing price yesterday and their work is almost 40 years old...
  - pfg 11y ago
    > You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger. That's a weird thing to say. If you manage to bypass file system access rules, there's any number of ways you can get access to the password manager. I'm not convinced that any measure 1Password could take to make this harder would amount to more than mere obfuscation, with the cost of additional complexity (and attack surface).
matthewmacleod 11y ago
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?

kazinator 11y ago

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 number. If I have some program binary which authenticates plain text passwords over an IP socket, I can probably find the "struct sockaddr_in" image of that address and change it to something else with a hex editor, to have that communication go to another machine. I'm not saying that this is the exact exploit; that would be a strawman: rather that there is potentially a very small code or configuration difference between a secure program that sends plain text over an IP socket, and a misbehaving one.) Of course, the path in a unix socket could also be tampered with; at least it won't go off box, though. The rogue piece listening to for the connection has to be planted on the same machine.

roustem 11y ago
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.
- kazinator 11y ago
  Indeed, it would be particularly amazing if a browser extension did that on Windows. :)
- julie78787 11y ago
  But even if they could, UNIX domain sockets aren't immune to attacks. That sort of the problem with "First, assume your machine has been pwn'd".
  - kazinator 11y ago
    Yes; if we assume the machine has been pwned, then whatever we can still trust is anywhere else but in that machine. At best we can come up with ways to securely smuggle bits through the pwned machine between two trusted endpoints; but we cannot manipulate any secrets on that machine. (Trusted computing relies on some tamper-resistant core of the machine not being pwned when the rest of it is pwned.)