1Password Leaks Your Data
myers.io
myers.io
You'd never encrypt a password but leave all the filenames/directories viewable without the password...
(I've noticed this before when grep-ing for a domain, and it came up with stuff from my 1Password vaults, but couldn't work out a better solution so still stick with 1password ). Its a shame, because 1password is great in almost all other aspects.
I would prefer that my account info be encrypted, but I can't use the new OPVault format, because it requires 1Password 5, which isn't supported on OS X 10.9.
In my opinion, when they came up with the new data format (OPVault), they should have made some kind of in-app notification/workflow to let people automatically convert to this new format. Nobody reads all release notes, it's impossible. If you're not a computer nerd, you're using the old format forever. I've also complained about this on their blog at the time.
By the way, the fact that not "everything" is encrypted is - sadly - also stated on their website: https://support.1password.com/opvault-design/
> The Agile Keychain kept some information (most notably Location and Title) unencrypted so that these could be used to search for or identify a particular item, while the more sensitive content could remain encrypted. With the Agile Keychain format, the browser extensions could identify and list potential matches for a website without having to be “unlocked”. With the OPVault format, we have moved away from that. The user must unlock the data with their Master Password before they can see a list of Logins.
I'm still not convinced that it isn't acceptable to leave your filenames/usernames still visible without the password for ANY password manager.
The first point is a valid concern, but minor. His second point is really only relevant to this 1password service.
Reason I ask is because I use pass + remote git server. Pass doesn't encrypt the filenames so the files are easily searchable. Are there any risks to this method?
Password-wise it is as safe as my ssh key + gpp key, so pretty strong. Metadata wise it is as safe as my ssh key + gitlab account (still pretty strong), or my linux session (WEAK).
Then again the same goes for any password utility I guess, since you can view passwords stored in browsers in clear text anyway.
You are talking about an outdated data format which AgileBit had dropped. They already provide OPVault to solve the problem. What do you expect they want to fix?
Some of the readers may only skim the title of this article / They don't understand the technical details. So they will assume that 1Password IS NOT SAFE. It's a minor bug which will affects almost no one. But this article ( Title ) will affects so many people's impression on 1Password. You are just writing an article to punish AgileBit.
(Update: I was wrong about the Agile Keychain being dropped. It's still using in Dropbox Syncing but iCloud/CloudKit)
https://support.1password.com/switch-to-opvault/
According to them, if you sync to dropbox or an external folder and use their default external file format for it, you might expose metadata, otherwise, you're fine.
As a very recent 1password user: Make the more secure format the default for new installs. Enable migration to that format without this braindead[1] process.
[1]: https://support.1password.com/switch-to-opvault/
They charge upwards of $60 for a full Mac/Windows/iOS suite of this software. I really don't think this is asking much.
I would never have started syncing with Dropbox had I known this. They have access to my site list now.
The article has very limited technical details to avoid confusing people who don't know what they are doing, but the reality is that if they are reading my blog, or are reading HN then they have the technical details to understand something much more complex than what I wrote.
I clearly state at the bottom of the article that the software still keeps your passwords secure and that I will continue to use 1Password. AgileBits still have my full support, I just want them to inform the users the downsides of using agile keychain, and to use OPVault by default.
My point being why you are talking about these issues in YCNews but their forum. Most of us just read 140 characters but an article, This is how information transfer today. I'm not finding excuses for AgileBits. The problem you mention need to be fix. But it's important where you talk about it. If there's a news said your product 'Leaking your data' in YCNews, and everybody will know that '1Password is leaking data', but 'The author of this article is still using 1Password'.
This is the flip side of "software as a consumer product" that sells for $60. If it's open source, the author could have discussed it on the bugtracker, posted to the mailing list / forum, or even just recompiled to use the old format by default, and you would have been justified in asking them to do so.
A commercial product that sells for $60? That's like a toaster oven or something. If my toaster oven is malfunctioning, I'm not going to go complain on their forum, I'm going to air my grievances in public and demand a new toaster (in this case, an updated version of 1Password).
Are you telling me that I've got a choice between the safety of my data and dropping functionality for which I paid for? Do you even know if OPVault works in the Android client? But forget Android, does it work with Dropbox syncing? Some posts from their forums claims it doesn't.
Also this isn't a bug. It was a conscious design decision. Now I wonder if I can ask for a refund.
I ended up just buying the Windows version because I was so tired of 1Password Everywhere.
> Well, in December 2012, AgileBits changed the format of their keychain from the Agile Keychain, to OPVault. So how is this new format? Well the first thing is that you cannot use 1PasswordAnywhere with this format any longer.
And:
> Let me summarise: Do not use the Agile Keychain format. It leaks your data. If you are using it, convert it to the OPVault format immediately.
That's lots of metadata, but probably doesn't help you in the slightest in guessing my password. Agree with you that its problematic that 1password was leaking things like site names and URLs though.
I personally typed or copy-pasted all the entries in my keepass vault, it's primary information associated with the passwords, highly personal, and that it's not the definition of metadata. The fact that a tool automates the gathering of some data (URLs) for the user doesn't automatically make it metadata.
Metadata would the character encoding, version, encryption, ids required to read the file, as well as added/modified dates (potentially sensitive metadata).
Also, whatever the unusual definition of data you use that results in metadata being excluded is irrelevant (and it is unusual, look up the definition of data in any dictionary). The important part is that 1Password was not making it clear that it does not encrypt certain parts of the "information" you put into it.
And I'm not using an unusual definition of data, that begs the question. My point is just because it's about you, doesn't mean you own it.
Is there, actually, in this context? What is the reason you're drawing this distinction? What makes generated passwords 'data', but password reset urls and hand-typed entry names 'metadata'?
Why shouldn't my password reset urls be private? They are... in the password database I use.
Why shouldn't my database entry names be private? They are... in the password database I use.
Are you saying that these things are metadata in 1Password by virtue of the fact that they weren't secured? Because that would seem like circular reasoning - that you can never leak data, because leaked data is metadata. I don't share your definition of metadata in such a case.
Are you saying that these things are metadata in 1Password because they shouldn't be private? I just plain strongly disagree if so.
Are you saying that these things are metadata because users shouldn't expect a password database to secure them properly? Then I could at least see where you're coming from. But I don't think it makes sense to tie the definition of metadata to that - among other complaints, I think it lets off companies/software that leak your (meta)data off far too easily, and that such word games absolve them of too much responsibility.
I've been intentionally vague so as to discuss this in more macro terms rather than the specific case as presented here, because I feel there's a panicked "deer in the headlights" attitude that comes with talking about data and metadata, and I'd like to try and help folks think a little more rationally around the topic rather than simply "EVERYTHING RELATED TO ME IS MINE AND NEEDS TO BE ENCRYPTED AND HIDDEN".
I regularly forget about how closed-minded the HN userbase is when it comes to privacy.
You may want to lead with that next time - I'm not the only one attempting to interpret your vagueness in-context (that is, in the specific case as presented here) which apparently isn't your intent. Hopefully it'll generate productive discussion instead of a confused chorus attempting to clarify terminology.
> I feel there's a panicked "deer in the headlights" attitude that comes with talking about data and metadata
Are you seeing that in this thread? Or is this more of a generalized feeling of HN? Or of the internet?
I feel like I'm mostly seeing discussions about what specific data was involved, what alternatives are out there, and the severity and history of the problem (which I'm seeing as mostly "not as severe as your initial kneejerk to the title might imply, but not ideal either" - pretty levelheaded and accurate, IMO?)
None of them seemed particularly frozen, unable to move forwards, or panicking beyond the time it took them to evaluate what specific (meta)data was leaking - to me, at least. And given that password databases secure the keys to the castle, so to speak, I'm not sure a little panicking isn't warranted in this specific context.
> I regularly forget about how closed-minded the HN userbase is when it comes to privacy.
If that's in response to this thread, keep in mind that, in-context, the "privacy" many professionals in here are concerned about, is the "privacy" of their amazon account keys, to avoid their servers being subverted into part of a malware distribution botnet. And the "privacy" of their user database - to avoid the reputation hit that comes when all your customer's passwords are cracked, and their inboxes are flooded with porn spam. I think it'd be a mistake to overgeneralize that response.
In the future, remember this when you decide to dissect someone's writing.
Quoting entire paragraphs may not be sufficient to provide proper context, and especially if being willfully misinterpreted, can be potentially harmful.
But well intentioned quotes, immediately under a post providing them in their full context - which is the case in my post you replied to? I'm hard pressed to see that as distorting your meaning and harming discourse. If you have specific grievances as to how I have, please state them. If my understanding is distorted, there is harm to discourse regardless of whether or not it's visible in the form of distorted quotes.
The many questions I'm asking are my attempts at understanding the context of your statements, to avoid such distortions. The couple that you've answered have clarified some things. A couple more have been mooted by indirect responses. Many others are still relevant and unanswered.
Even now, I'm a bit unsure if you're saying that I've done harm, in the specific post I made that you were responding to - or if you're making vague generalizations again, this time about sentence level quoting on the internet in general. I'm assuming the former for now - but please correct me if I'm wrong. I would ask, but that's clearly not working out for me.
Public metadata isn't mine. Private metadata is. And in fact, around here it's illegal to record my metadata, even if publicly viewable - anti-piracy groups have been fined for producing databases of IP addresses+shared files taken from the Bittorrent network.
"1Password Leaks Your Metadata" would be both more accurate and less clickbait.
In what possible way would this headline not be more accurate if it were "1Password Leaks Your Metadata"? How would that be diminishing different peoples' risk assessments?
They seem receptive to that kind of thing.
The fact that he subscribes to such a site though, would be worth gold in expose articles and/or blackmail...
Here, I fixed it for you.
This works amazingly, and it's the only way I know how to have distinct individual logins and share common passwords (most other solutions would require we use the same iCloud login, etc.)
The agilekeychain is in a folder that only our Dropbox users have access to. Where, again, is the part where the whole internet can see it and Google can index it?
If you have your sync set up to be generally visible on the entire web, aren't the passwords (encrypted) also there? I operate under the assumption that my keychain itself hasn't been compromised and if it has I've got a ticking timer to reset important passwords. If it were on the internet, I'd better be spending time every month rotating passwords since I would have to assume attackers were always at it.
So what's up with this "visible in a browser" thing, and why would anyone use it in the first place?!?
That happens to people who self-host the file. That aside, Dropbox (the company -- or any other person that has access to your agilekeychain, for that matter), having access to metadata about your encrypted passwords is already bad. They shouldn't be able to see anything -- not just your passwords, but also the sites they're for (sexwithanimals.com, hilterappreciationsociety.org etc.).
>If you have your sync set up to be generally visible on the entire web, aren't the passwords (encrypted) also there?
Your passwords yes. Their metadata (such as that they're for sexwithanimals.com and hilterappreciationsociety.org etc) not.
I seem to recall that the original justification was that it allowed for checking to see if 1p had a login for the current site without having to ask for your password to decrypt the db.
My understanding is that the new format addresses the issue, but it hasn't been rolled out to the dropbox sync yet.
Hopefully the noise here will push that ticket to the top of their priority list :)
http://taoofmac.com/space/blog/2011/04/28/2233
(edit: Just noticed that someone else also linked to my blog post further down. Apologies for the redundancy.)
If by people you mean "people in general", just look at their respective website. The answer is rather obvious.
I contemplated over which password manager to use before deciding on 1Password simply because of its simplicity and usability. I try to be as aware of my privacy and security as possible and even though I was aware of this leak beforehand, I went with 1Password anyway.
"Hacker News crowd" (to be clear, I'm not using this in a derogatory way) usually think about security in terms of how things work technically, but practicality is just as important. If some piece of software is secure but not usable, that doesn't do any good to the user.
KeePassX is plain ugly, has a terrible website that doesn't give any confidence and scares the user by giving them technical details right out of the gate (check their website). I get that it's open source, it's free, probably more secure than 1Password and they most likely don't have enough income to hire as talented designers as AgileBits already employ, but that just doesn't matter to the user.
Come to think of it, I shouldn't have said that because I have no empirical evidence one way or the other.
That wouldn't be a problem if you didn't have a bunch of followers who believe every word you say. But you do, because your analyses are usually decent quality.
I was disappointed that you had something to say about that password vault, and then didn't say it. You opted for this weird gray area of "I have more than a hunch it's less secure than 1Password." Huh?
Maybe you have nothing to say. It's really strange to see you drop to hunches from substance.
One of the best pieces of advice I found on HN was when someone told me to unplug. It helped me a lot. When you start to see everyone as a troll, it might be time to step back a bit.
They are working on 2.0 in the git repo too (https://github.com/keepassx/keepassx/commits/master)
* The screenshots are from 2003 era software (XP & Mac OS X 10.3)
* The requirements page says "Qt Library >= 4.3". Does that come with Windows?
* The downloads page doesn't specify if it work on Windows 8 or newer, or Yosemite / El Capitan for Mac.
* The website appears to be running an outdated and exploitable version of Wordpress, and is broadcasting its version number in the site source code.
And an actual quote from their support forums:
"I've got to say this is the deadest forum I have ever joined. There's so little help here that I'll advise anyone who can't figure things out for themselves to pay-to-play one of the bigger, commercial password managers. I'm done here - I don't see any reason to return."
This is common to a lot of open source projects. A product is not just the code, it's about usability, building trust, educating users, explaining things in a way they understand, and providing timely & friendly & helpful customer support. Code is barely 10% of a product. People pay for software because they want a job done well, and they don't want to spend more time than necessary on it.
ADDING A SECONDARY VAULT EFFECTIVELY MEANS STORING MASTER PASSWORD OF YOUR SECONDARY VAULT IN YOUR PRIMARY VAULT!
This was confirmed by their support as a reply to my email below. It is better for UX, but it is not explained properly IMO.
Theoretically you could get burnt in scenario when you use personal primary vault with some weak-ish password and add your super-important employer's vault as a secondary vault for convenience. You effectively make super-important vault as weak as your weak-ish master password of your primary vault (without knowing).
My email back in March 2014 (shortened):
I somehow ended up in situation where 1Password pretends to keep my data safe but does not require password for unlocking secondary vault as long as I have unlocked the primary vault. If I don't unlock primary vault and switch to the secondary vault first, the correct secondary master password is required. [Contrary switching to primary vault while having unlocked secondary vault requires me to enter primary master password to unlock it (expected behaviour)]. This behaviour is exhibited in 1Password.app, 1Password mini and chrome plugin.
I'm a developer. I have just read all the documentation available on your site http://help.agilebits.com just to better understand the system and reason about it. And I cannot really explain this behaviour. 1Password should not know how to unlock my secondary vault without my secondary master password (unless it caches the master password somewhere behind my back) OR my secondary agilekeychain file is not really encrypted, but UI pretends it is, because it requires correct master password (when I go and want to see the secondary vault without unlocking the primary vault first). I noticed this behaviour only recently I think originally this worked just fine. This hiccup could be caused by latest update or my upgrade to 1Password4 a few months ago.
The discussion and analysis in Dale Myers' article is very good, although someone who just reads the headline could very easily come away with the wrong impression.
The "older" .agilekeychain format (AKF) — designed nearly a decade ago – does indeed expose the same sorts of information that would be in someone's browser bookmarks. So if someone gets hold of your AKF data they will be able to see what sites you have Logins for and what titles you have for your items.
Given the constraints we faced back then, that might have been a reasonable design choice at the time. But it is certainly not an acceptable design choice today.
The article does point out that that the OPVault data format was introduced as a replacement for the AKF back in December 2012. The OPVault format not only encrypts much more of the metadata, but it also provides for authenticated encryption and includes many other improvements.
The article also points out that the behavior of the AKF "discovered" is documented in many places. We've blogged about it, we've talked about it on our discussion forums and it is in the docs. What isn't in place is some big red letters in the user interface that says "Using this format leaves URLs and Titles unencrypted".
Dale Myers' article also correctly points out that we do offer instructions on how to migrate your data from the Agile Keychain format to OPVault.
The article criticizes us for (a) Not making OPVault the default for new Dropbox synching, and (b) Not providing a nice easy way to migrate
Obviously we would love to see everyone on the new data format. It is a big improvement over the old one in an enormous number of respects, but until we can be confident that everyone is running clients on all of their platforms that can handle the new format, we are treating migration as an "expert only" thing.
Rolling out a data format change when you have one "product" and one platform is easy. But we need to make make sure that people are using versions (and that such versions are available) of 1Password that handle the new format on all of the devices that they sync with.
So if we were to make OPVault the default sync format on Mac, we would need to know that the 1Password app people are using on Windows. We have been conservative about this.
Also, in our beta testing of data migration, we discovered a nasty bug in how we encoded keys for the some attachments. The result is that some of our beta testers would have lost data if they had not had good backups of their AKF data. Obviously, that is not something we wanted to push into general release. (Only attachments created in specific circumstances were victims of that, so we didn't spot it in internal testing.)
Now you may very well disagree with some of our judgement calls, particularly about how cautious we have been and continue to be in migrating people to the new format. But I hope that even if you do disagree, you will see that there are reasons for our choices.
Preventing data loss is part of data security. So many of these decisions aren't so much a "security v convenience" decision but a "security v security" decision.
I'd rather they protect their user's data. ;)
I'd rather be inconvenienced if I know my data is safer.
Also, it's been 3 years since OPVault first came out. How careful can you be?
If even just 1% of our customers end up synching a .agilekeychain on some devices and an .opvault on others, they will get data that slowly drifts apart. And we've grown kind of popular over the years. 1% of users is a lot of people.
Our transition from OS X keychain to Agile Keychain back in 2009 was an rough experience for customer support. And back then we were Mac only.
I'm not saying that the wait hasn't been longer than it should be. But our plans for a swift transition didn't work out as we would have liked.
But sophisticated users can switch to OPVault in most cases. See https://support.1password.com/switch-to-opvault/ for instructions.
The difficulty is that when you set thing up, we don't know what other platforms you will set up for. Since OPVault (still) doesn't work everywhere, we leave switching to it an advanced process.
We've thought about adding a screen that asks "Will you by synching to devices using 1Password for Android or 1Password for Windows prior to version XX or 1Password for Mac prior to version YY?" and then using OPVault if their answer is "no".
But a mere warning about what metadata is and isn't exposed, without something that people can easily do is just going to confuse most people more than help.
There are definitely ways to present these options without getting super technical, I know that, like the security underlying these options, there are trade offs, but having the only option being me opening a terminal and running defaults, after searching in rage, this can't be the right trade off, it just can't.
It seems like there's no communication around this at all, despite the fact that it's been three years since the change was implemented.
And beware - trust is hard to earn, but easy to lose.
I'd rather lose some functionality than leak metadata. Let us make that choice of tradeoff.
Wouldn't this be "self fixing" problem, if you use 1Password to comeup with a secure Dropbox password?
Obviously this isn't ideal situation, but I see no reason to switch away from 1Password and currently I don't even know where I would go from 1Password. I jumped from LastPass to 1Password since I want to have access to my passwords on mobile devices without paying a yearly fee and now that LastPass has been acquired by LogMeIn I'm in no hurry to jump back. And I don't know if opensource managers like KeepPass have mobile support.
I'm a little less concerned... though, I use LastPass, I used to use KeePass on dropbox, but lastpass has better integration into the browsers on the platforms I use (less good on android with chrome though, and there's the fee). I don't know that there's a better option that's as seamless for users.
This is like people uploading their private RSA keys to Github
Long tangential digression:
My personal design goal is to maximize the number of distinct entities which have to collude to cause me serious harm.
Pure online SaaS is often very bad. There are cases where the risk is acceptable, but "here, maintain a password list" is not one of them. The "shared google sheet full of password" is a great example of this. Evernote is another example. I avoid these wherever possible.
Systems like LastPass where the binary is distributed by an entity every time I use it, and then talks to that same entity for the backend, are are better, but still bad. Hushmail was the canonical honeypot of this type -- download a java applet after logging in...
A long-lived binary (standard client software) talking to servers operated by that entity is better. Swapping the binary out is more detectable, and harder to do for a single user. iOS apps are probably the best for this right now, since Apple is sort of a semi-trusted intermediary here. You'd at least have a shot of catching the compromise after the fact.
Client software which talks to servers run by separate third parties is better. e.g. 1P using iCloud/Dropbox. It is better as the set of third parties is bigger and more diverse.
The ideal is being able to run client/server on your own platforms. Being able to run a cloud storage service (e.g. AeroFS) entirely on your own private network is ideal.
Open source on top of this is great, but in reality independence of operating the services is worth more. An open standard with multiple implementations, many of which are open source, would be meaningful, but merely publishing source code isn't as meaningful, at least without verifiable/repeatable builds and a good runtime level matching.
Edit: like -> unlike
1. This doesn't apply to local data
2. This applies to metadata, rather than passwords
3. This only applies to an old vault format changed in 2012 used for syncing via external servers [edit, specifically dropbox or folder sync, still in use for that it seems]
So 1Password leaks your metadata if you use the old vault format from 2012 and upload your passwords to a public service (or share them some other way), but that's perhaps not such an upworthy headline.
Personally I would use local wifi sync and keep your data local, whatever password manager you're using.
I'll try to remember to poke around the data files this week if I get a chance.
Yet more proof of time travellers..