1 password mini traffic — password in plaintext

variousred · February 2015

For fun I was capturing some traffic from one password mini to see what was transmitted, and I discovered something alarming.
Sitting there in a plaintext file on my desktop was my password to a site I had logged into:

traffic snippet

{"action":"fillItem","payload":{"options":{"animate":true,"autosubmit":true},"action":"fillLogin","item":{"uuid":"F2D6CB7D38688D0052595E018C42E2E1","nakedDomains":["pivotaltracker.com"],"overview":{"title":"Tracker ‚Äî G5","url":"https:\/\/www.pivotaltracker.com\/signin"},"secureContents":{"htmlForm":{"htmlMethod":"post","htmlAction":"https:\/\/www.pivotaltracker.com\/signin"},"fields":[{"value":"REDACTED","id":"credentials_username","name":"credentials[username]","type":"T","designation":"username"},{"value":"PASSWORD-REDACTED","id":"credentials_password","name":"credentials[password]","type":"P","designation":"password"},{"value":"","id":"remember_me_checkbox","name":"remember_me","type":"C"},{"value":"Sign In","id":"signin_button","name":"","type":"I"}]}}},"version":"01"}

end snippet

I've replaced my actual sensitive information with REDACTED, but it was definitely in there.

I'm guessing this is just getting sent between mini and the full app, but I read another discussion on here that said once connection is established that all traffic is secured.

This has got me nervous!
Please help

Michael

MikeT · February 2015

Hi @variousred,

That information is being sent from 1Password mini to your browser extension to fill in your data, we use these data to match the fields on the site before filling it.

However, it should be done via a secured websocket connection. Are you monitoring the traffic from the websocket connection or from the extension in the browser? If it is in the extension, that's normal as we need the decrypted data to fill in.

Can you tell us how you're doing this, so we can see what's going on?

Thanks!

variousred · February 2015

I'm using Little Snitch (an outbound firewall) to capture the traffic

littlebobbytables · February 2015

Hi @variousred,

I've conferred with the devs and I think it will be best if we ask our security guru @jpgoldberg to pop his head in as to why we use a web socket rather than a secure web socket.

I can replicate your findings as I'm also a Little Snitch user. Saying that, I had to go peruse the help page as I didn't even know you could tell it to monitor a particular app - clearly I'm not a power user of it (neat function by the way).

Let's see what @jpgoldberg says.

jpgoldberg · February 2015

Well spotted @variousred!

If you have malware on your computer which can listen to the traffic between the 1Password extension and 1Password Mini then it can capture the passwords that are transmitted that way. There should be a document on this "any day now", but that "any day now" has actually been more than a couple of months.

The generic answer

The generic answer is that in principle no software, including 1Password, can defend itself when running on a compromised system. After all, malware running on your computer when 1Password is unlocked can simply extract the decryption keys from system memory.

But with that said, there certainly are things that we can and should do to make some malware work harder. See, for example, what we do about keystroke loggers in Watch what you type: 1Password’s defenses against keystroke loggers.

The specific answer

To be perfectly honest, we aren't entirely sure what we can or should do about this. We've had extensive internal discussions, but no resolution. The difficulty is that while we could encrypt that traffic, the encryption keys would need to be stored within Mini and the extension unencrypted. That is, it would be encrypted, but with obfuscated keys.

The only way to not store a long term key would be to have the user "pair" Mini with the extension every time they start the browser. That is, the first time you use the extension after a browser restart, you would be prompted for something similar to Bluetooth pairing or 1Password Wi-Fi sync pairing.

So that leaves us with (roughly) these options.

Try to obfuscate key used for Mini-Extension communication.
Leave things as they are
Require user driven pairing each time a new browser session is launched.
Use system and browser specific tools in an ad-hoc manner
Introduce our own web browser as we do on iOS and Android

I'm not going to talk about that fifth option.

Problems with obfuscation

So far we have rejected obfuscation because we would expect such obfuscation to be broken. For example the "obvious" thing to do would be to use wss:// (websocket with SSL) instead of ws:// (unencrypted websocket). But that would require that Mini (or Agent on Windows) to have a certificate with a private key in operation. It really isn't hard for an attacker to extract the private key from such a process if the attacker already has some powers on the local machine.

If the obfuscation is broken without a public announcement of that break, we would have the most dangerous situation: Where something appears to be secure, but is actually broken and exploited. So, sure, using something like secure websocket for the communication would mean that the attacker would need to take an extra step (extract the private key from a running Mini). But us doing so would be presenting a kind of security that cannot be relied upon. (A similar argument holds for our decision not to obfuscate unencrypted data in the Agile Keychain format.)

Problems with explicit pairing

We have rejected session pairing because of the added complexity for the user. Furthermore, it wouldn't solve all of the problems, so it would be a great deal of added complexity for a relatively small gain. Normally I like to say that there isn't a "security versus convenience tradeoff", but in this case there is. This would involve a large burden on the user to defend against a relatively narrow threat.

Now we may eventually have to go down that road. We won't like it, but if we have reason to believe that people's systems are being attacked in that fashion, then we will have to look at such mechanisms.

Ad-hoc approaches

We could get around some of the obfuscation problems by tools available specific browsers and situations. For example, we might be able to allow 1Password Mini and our browser extension in Safari to share a secret via the OS X keychain.

One of the problems with this is that we are far from certain that we could get this to work in a way that would prevent malware from getting at the secret. Remember, the initial attack is assuming malware running with at least the user's privileges while 1Password is in use.

The second problem is more of a developmental and maintenance problem from our end. We've worked hard to build a browser extension that works the same in all browsers and on both Windows and Mac. Some of the old timers here may remember the days when we had to release a new version of 1Password every time there was a browser update. Sometimes browser updates would break 1Password. We really don't want to have a different protocol for extension/Mini communication for different browsers.

Problems with leaving things as they are

For the moment we are staying with "leave things as they are". I can't pretend that we are happy about this, but it seems like the least bad choice at this time. But I should make it clear that we are not doing so passively. We are fully aware that this is publicly known avenue for attack, and so we are keeping an eye out for any indications that it is being attacked.

At the same time, we continue to remind people of the generic answer given above. Sure there are things that we can do to defend against some malware running locally, but in principle that is an arms race that we can only lose in the end. So to keep your systems free of malware

Keep your system and software up to date
This is the single most important thing you can do to keep your system free of malware
Install Microsoft Security Essentials on Windows 7
OS X (since 10.7) and Windows 8 have built in anti-malware systems that run silently
Be selective about what you install on your computer.

The problem with our current approach is that we are also placing a burden on the user to keep their systems free of malware. While we can justify this delineation of responsibility, thus covering our backsides, is it an approach that best serves people using 1Password?

variousred · February 2015

Good stuff, thanks for the very detailed answer