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)
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'.
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.
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.
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.
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.
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.
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.
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. ;)
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.
This is like people uploading their private RSA keys to Github
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.
* 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.
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.
They are working on 2.0 in the git repo too (https://github.com/keepassx/keepassx/commits/master)
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.
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 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.
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.
"1Password Leaks Your Metadata" would be both more accurate and less clickbait.
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?!?
> 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.
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 :)
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..
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.)
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.
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
