1Password Leaks Your Data

[app103]

For those of you who don’t know, 1PasswordAnywhere is a feature of 1Password which allows you to access your data without needing their client software. 1Password originally only used the “Agile Keychain” format to store their data (not including when they were OS X keychain only). This format basically stores your data as a series of JavaScript files which are decrypted your data when you supply your master password. Since the files are JavaScript and implementations of various crypto algorithms exist in JavaScript, there was no reason why AgileBits couldn’t come along and make a HTML and JavaScript client for viewing your data, so they did.

If you browse to your .agilekeychain “file” on disk, you find that it is actually a directory. Inside this directory is a file named “1Password.html”. If you access this file over HTTP (note that using the file protocol won’t work), you will be greeted with a grey page which has a lock image and a password field. Enter your password and your keychain will unlock and you have a read only view of your data.

So what’s the problem? Well, it turns out that your metadata isn’t encrypted. I discovered this after having a sync issue with Dropbox (I use Dropbox to host my keychain). The file that had issues was 1Password.agilekeychain/data/default/contents.js. Being a curious kind of guy I opened the file to see what was in there. The answer is the name and address of every item that I have in 1Password. Every single one. In plain text.

The implications of that are rather serious, in some cases. To understand just how serious and hear what 1Password had to say about all of this, read the full article.

http://myers.io/2015/10/22/1password-leaks-your-data/

[wraith808]

I just checked this with mine.  Everything is correct, up until the last line.  There are no passwords stored in that file.  Just the addresses of the sites.  An example from my file for DonationCoder:

["redacted a guid","webforms.WebForm","DonationCoder","http://www.donationcoder.com/forum/index.php?action=login2",redacted an integer,"redacted another guid",0,"N"]

I redacted parts just in case (2 guids and a number), but none of them were passwords.  I might wish that the sites were not stored in this manner- but the passwords are just not there.  I even looked for a couple in the file and the directory that I know are stored in my 1Password, but none of them are in any of the files.

[app103]

I just checked this with mine.  Everything is correct, up until the last line.  There are no passwords stored in that file.  Just the addresses of the sites.

The article never said it was leaking password data.

The meta data can present just as much of a privacy or security issue, in some cases, depending on what's in there and where you store your keychain file. It's pretty much a list of every site you have a login on. And as the author stated, it could also contain password reset URLs that are not one time usage urls.

1Password has always known about this issue but doesn't seem to really care about it (it was a deliberate design decision), and doesn't inform their users about it. I wonder how many of their users just assume this data is all encrypted, because they haven't been told otherwise.

People get upset when their government wants ISPs to save a history of every URL visited by each of their customers, to be made available to them upon request, calling that an invasion of their privacy. How would this kind of data about 1Password users, made available to the public in plain text (depending on where you store your keychain file) be any less of a privacy risk?

[wraith808]

People get upset when their government wants ISPs to save a history of every URL visited by each of their customers, to be made available to them upon request, calling that an invasion of their privacy. How would this kind of data about 1Password users, made available to the public in plain text (depending on where you store your keychain file) be any less of a privacy risk?

Point taken about the passwords.  I read that wrong.  Which, to me, makes it a lot of sturm und drang with no foundation.  The difference in your analogy is that the ISP is not under your control.  This data is.  Just like if you store a list of URLs then post it on the net.  Why would you post this information in a publicly accessible location?  You wouldn't, from my estimation.  And if you do... then that's your fault, isn't it?

[Stoic Joker]

1Password has always known about this issue but doesn't seem to really care about it (it was a deliberate design decision), and doesn't inform their users about it. I wonder how many of their users just assume this data is all encrypted, because they haven't been told otherwise.

I'll go with the perilously close to 100% range. Aaannnddd... Therein lying the problem, because with the false assertion that all is fine-ly encrypted more people will be prone to expose the file publicly (for their on access/convenience) and subsequently end up hemorrhaging much useful personal data.


All data is (mis)useful...it's just a matter of figuring out how.

[hamradio]

Also the case of what about web browser history if you don't clear the history/cache all the time and have one of those reset password website addresses in it that doesn't expire? Same thing going on there I would think especially if computer was compromised...

[JavaJones]

It seems there's more to the story, and a fix is on the way:

The team introduced a new format called OPVault in 2012 that encrypts a lot more metadata. Concerns over backwards compatibility with Android, Windows and Dropbox synching, however, convinced them to take a conservative approach and not automatically migrate everyone over to OPVault.

Myers’ post, the team said, reminded them that it was time to make the switch to the new format. As such, they’ve already started transitioning to OPVault. For those that don’t want to wait it out, it’s possible to manually make the switch using these guides for Mac, Windows, iOS and Android.

http://www.techspot.com/news/62488-1password-changing-data-formats-boost-metadata-encryption.html

- Oshyan