[ikeboy]

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 action would need to be done every time either the browser or 1Password mini is launched.

Why every time? The first time, yes, and then each side stores its key. Future connections must handshake on that shared key, so you aren't talking to an imposter.

You still lose against root malware, but threat still seems to strictly decrease.

[jpgoldberg]

The browser would have to hold on to the shared key long term. Where does it put this?

Encrypting with a key that is available to attackers (who have the same set a privileges needed to run localhost sniffing) is not encryption. It is obfuscation.

[ikeboy]

I thought the point of the arxiv paper was that a non privileged app could effectively "sniff" by pretending to be the other app.

If I'm understanding correctly, that means that encrypting with a shared key helps. Am I missing something?

[roustem]

1Password verifies the code signature of the apps connecting to the WebSockets server using SecCodeCheckValidity.

That would prevent connection from the apps that do not have their code signature whitelisted.

[ikeboy]

From the paper:

>WebSocket. WebSocket servers are typically built over a few popular opensource frameworks, such as CocoaHTTPServer [3] and QtWebKit [14]. All of them provide a receiver method for getting messages from browser extensions, which is used by Xavus to fingerprint this channel, and a response method for replying to the extensions. The invocations of these two methods are identified as the claim and the use of the channel, respectively. Between them, the server is supposed to access the HTTP header Origin that includes extension IDs attached by the browser and check the signature of the browser through the API SecCodeCheckValidity. If these operations are not found, the app is considered vulnerable to the threat from a malicious extension or app. On the other hand, the attack from a malicious server against an extension cannot be detected through any existing APIs.

This sounds to me like the app validates the extension, but the extension can't validate the app. In that case, using a shared key helps.

[drhayes9]

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.

[ikeboy]

http://arxiv.org/abs/1505.06836

Other non root apps can masquerade as the app intended to get the data, and if it's sent in plaintext, they get information they wouldn't if it used a shared key accessible to the intended app.

[nbadg]

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.

[ikeboy]

But then malware must run as root.

[julie78787]

Not necessarily. Malware only requires privilege if it is violating a security policy. There are a variety of attacks in which a process executing as a user is able to access resources controlled by other processes which are executing as the same user.

[CiPHPerCoder]

"Let's throw encryption at the problem" isn't always wise.

For example: https://paragonie.com/blog/2015/09/comprehensive-guide-url-p...

What do you need to do before you can sniff a loopback interface?

[ikeboy]

http://arxiv.org/abs/1505.06836

You can run as a regular user (or even sandboxed) and connect to the interface without authentication.