Language-based Defenses Against Untrusted Browser Origins

ericb80 · August 2013

This paper here presents a security problem in connection with 1Password:
https://www.usenix.org/conference/usenixsecurity13/language-based-defenses-against-untrusted-browser-origins

Has this been addressed?

jpgoldberg · August 2013

Hi @ericb80,

I can't give you a full answer until we've studied this more. However, over the past years we've discussed the 1Password-specific issues with Karthikeyan Bhargavan, the lead author of the paper.

Short Answers

One short answer is that one of the issues has long been fixed and the other is being fixed through our transition from the Agile Keychain Format to the 1Password 4 Cloud Keychain Format.

The other short answer is that if you look at Table 1 in the paper, you will see that 1Password is among the most restrictive in what it can be tricked into revealing, only a single password for a particular site (per successful attack). Other systems can be tricked into revealing their entire database, encryption keys, or general access tokens to the database.

Long answers

There are two particular issues, both of which would undermine 1Password's anti-phishing mechanism.

Tricksy URLs

The first is described as "buggy URL parsing". Karthikeyan reported to us (quite some time ago, I will need to dig through our change logs and communications to get dates and versions) that in some cases a web page could have an oddly constructed link leading to a page with an oddly constructed location that could trick 1Password into thinking it was on a different page.

At any rate this has been fixed for more than a year (again, I need to do some digging).

Active tampering with your data

The other way to defeat our anti-phishing mechanism is described as "the lack of metadata integrity in the encrypted password database format." That is, an attacker who obtains write access to your 1Password data (Agile Keychain Format) can tamper with it in such a way that 1Password could be led to believe that a website under the control of the attacker is actually a website for some service you use (such as a bank or an email provider in the worst case). Again, note that this attack requires the attacker to

Obtain a copy of your Agile Keychain format data
Modify that data in a particular way.
Leave that tampered with data where you will use it.
Have a phishing site set up pretending to be the genuine location but at the location that was injected into your 1Password Agile Keychain data.
Not have the phishing site caught prior to you using 1Password's Go and Fill feature for that site (or otherwise directing you to the bogus site)
Hope you don't notice that it is a phishing site through means other than 1Password's (now subverted) anti-phishing mechanism.

I am in no way trying to dismiss this kind of attack. Indeed, we were already working on defeating this at the time that Karthikeyan contacted us. But this is not something for which there was a simple fix. It involved a radical change to the kind of encryption used in 1Password, and so that "fix" is in our new data format: the 1Password 4 Cloud Keychain Format (until we come up with a better name for it.) As I said, we were already working on the new data format at the time.

Defending against passive attacks

When the Agile Keychain Format was designed 2007, our focus was only on "passive" attacks. What could an attacker do if they captured your data? We were early adopters of mechanisms like PBKDF2 specifically because we assumed that some people would have their data captured. But we did not consider the threat posed by active attacks.

Defending against active attacks

An active attack is where the attacker tampers with your data or with your communication channel and "tricks" you into processing that data. They have to tamper with the data and get you to use that modified data. The attacks against SSL/TLS that have emerged over the past couple of years (BEAST, CRIME, etc) are all active attacks.

In general, the way to prevent a very broad class of active attacks is to use what is called Authenticated Encryption. Before 1Password does anything at all with its data, it runs a cryptographic integrity check on in. This is done using a Message Authentication Code (MAC) that is part of just about every bit of data in the 1Password 4 Cloud Keychain Format. We've posted about the importance of MACs and Authenticated encryption on our blog.

Just as we led with the use of PBKDF2 seven years ago, we are also leading in introducing Authenticated Encryption. (I'm not claiming that we are the only ones, only that we are in the forefront.) But new data formats take time to roll out, even after they've been designed and publicly scrutinized.

JavaScript proposal

Because of how 1Password works and how our browser extension is delivered, the over all point of the paper isn't all that connected to 1Password. The particular proposals they offer (a restricted form of JavaScript, designed for security) doesn't affect 1Password. But in looking 1Password, they did find some active attacks could defeat our anti-phishing mechanism even if it isn't actually covered by the proposal in the paper.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

jpgoldberg · September 2013

I'd like to update this discussion a bit. As the phishing concern is getting rediscovered more frequently and is getting more public interest.

First let me credit Paul Moore, @Rambling_Rant on Twitter, for actually putting together the first actual demonstration of this. He actually set up a test phishing site and did performed a test of this.

But I'd like to discuss bits of a particular discussion on Twitter with Gordon Irving. And so let me provide a bit of the context for that that.

Gordon Irving @gordonirving:

. @jpgoldberg @1Password so you've been (and still are) selling a product that is less secure than a locked Pages file?

Jeffrey Goldberg @jpgoldberg:

@gordonirving A locked Pages file provides zero defense against phishing. @1Password 3 provides substantial defense (and much more).

Gordon Irving @gordonirving:

.@jpgoldberg @1Password can you please elaborate on both points?

In following discussion, I will be happy to elaborate on that. It just got far too difficult to do that on Twitter, which really isn't the best medium for elaboration.

jpgoldberg · September 2013

If I understand what Gordon is asking me to elaborate on, it is my assertion that

a locked Pages (or other word processor file) provides no defense against phishing, while 1Password presents some defense, and that
1Password provides much more than its anti-phishing when compared to a locked Pages (or text) file.

It's hard to really address the second point without descending into something that sounds like a sales pitch, and I was under the distinct impression that Gordon is not in the mood for such a thing.

But we do have a blog post that discusses some of the issues that people overlook when they roll their own password management schemes, including just using an encrypted text file.

Relative phishing defenses

How 1Password does it

1Password will not fill in data on a site if the site's URL doesn't appropriately match the Location stored in the 1Password item. So if you visit a site like http://phishme.ua/www.paypal.co.uk/sign-in in your web browser, but 1Password doesn't have a Login for phishme.ua then it will not fill in any username or password, much less your paypal password.

It doesn't matter how you are directed to the phishing site. Whether it's a link in some email or in some other page. 1Password's filling mechanism won't fill it.

Of course it will fill it if the attacker has managed to edit your 1Password data on a system that you get your 1Password data from. (That is, it isn't enough for the attacker to edit a copy of your data. You have to use the edited data) to change the Location for what you think of as Paypal to the phishing URL. That is the attack we are talking about.

1Password will not prevent you from copying your Paypal password to anything. Once you copy and paste the password, then the antiphishing mechanism is gone (it can neither protect your or be subverted.)

Usernames and passwords in a text file

Here I have to speculate about how individuals might set up and use an encrypted text for word processor file for password management. And so I will extrapolate from the way that I did it back when I tried to role my own.

I had a text file (encrypted with PGP/GnuPG) that contained lines. Each line contained a username, a password, and a service name and/or URL. When I visited a site (typically via browser bookmarks or searching or various links), I would just copy the password from the decrypted file and past it into the form on the web page.

It was just as easy for me to copy to a real site as to a phishing site. If someone could have edited my bookmarks or browser history they could have helped direct me to a phishing site. Or I could be fooled by an email or whatever.

Because the normal operation of this system was to copy and paste, there was no way to the data in my encrypted file to make it hard for me to give my password to a phishing site. The only way that data file could have helped me against phishing is if I only (or mostly) got to sites by using the URLs in the text file.

Now I can't know with any certainty how others use such systems. But they only provide a defense against phishing if the user only (or mostly) gets to web pages by following the links within their encrypted document.

The difference

Unless people are using their "locked Pages files" in ways that I find unlikely, they provide no defense against phishing.

An attacker who has write access to persons data (in a way that people will use the modified data) could direct people to phishing sites by editing browser bookmarks, browser history.

1Password, in its typical usage (but not with copy and paste of passwords) does provide a defense against phishing. However, if an attacker has the same kind of write access needed for things like browser bookmarks, then the Agile Keychain Format can be used to subvert 1Password's anti-phishing mechanism.

Anyway, this is the basis for my claim that an locked Pages file provides virtually no anti-phishing protection, while 1Password's is substantial.

-j