I don't get why people are making out this isn't a big issue - people would assume whatever is saved in the 'vault' is completely encrypted.
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.
> 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.
WinZip made a similar choice with its encrypted archives: you could see the list of directories and files before supplying a password.
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.
This is actually not the whole story. WinZip archives can be encrypted like you describe, but they can also be created with both the data and the list of contents encrypted.
>You'd never encrypt a password but leave all the filenames/directories viewable without the password...
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?
I have the same setup (pass [0] + private git repository via Gitlab).
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.
They're not exactly in clear text: Chrome and IE encrypt them with the Windows session key (meaning only software running as the same user can decrypt them); Firefox on the other hand encrypts them with 3DES-CBC using a master password, if you set one, which is supposedly secure even against software running as the same user.
As an user of 1Password and indie app developer myself. I don't think talking about this question in YCNews is not a nice gesture.
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)
That's absolutely not the case. My issue is that AgileBits need to push the new format over the old one. The old one is still the default. Most users, my self included, have no idea that the old format is insecure, or that a new format exists.
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.
The old format is not 'Default' but Dropbox Sync users. I'm using iCloud Sync and I'm not affect by these problem.
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'.
> My point being why you are talking about these issues in YCNews but their forum.
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).
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.
They're working doing that (it's already the default for local storage and iCloud, right?). I don't think the issue here is code as much as it is "you can't break people's already-deployed password vaults"; for a lot of their users, that kind of breakage is almost as bad as losing data.
Which would make sense, but isn't that an argument for appropriate warnings and a checkbox under sync preferences rather than functionally undocumented defaults hacking? This weakness has been public knowledge since at least 2012(!), so I'm forced to consider why they're so blasé about their customer's data.
I would never have started syncing with Dropbox had I known this. They have access to my site list now.
I'm a new client of 1Passwords and I bought licenses for OSX, Windows, Android and iOS because I'm a multi-platform kind of guy. I also have a Linux workstation and figured that I'll just generate passwords on my phone and then use the 1Password Everywhere dump on Linux. And I decided to use 1Password because it has this portable read-only interface.
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.
It may be an outdated data format, but they certainly haven't dropped it. It's still the default format for syncing, presumably because 1Password for Android doesn't support OPVault yet.
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.
Of the many password vault tools out there I still prefer ones that store the data locally, secure with published and and peer-reviewed crypto, sync directly across devices without uploading to a service. I just don't need the hassle of discovering belatedly that an online service has leaked any data. Especially if they are inclined to say it was by design.
Perhaps I wasn't clear in the article. This is an entirely optional feature. If you don't want to store 1Password in Dropbox you don't have to, and you certainly don't need to have it in your public folder (I'm not sure those are even a thing any more?). The concern is that if someone has access to your keychain in any way at all, it is open to this. Perhaps you left your machine unlocked for a few minutes? Set up a read only network share for friends to stream movies from you? etc.
I'm not sure I'm following you, but in short I'm not trying to attack this piece of software. All I'm saying is that I have a particular point of view and it appears based on the description that this tool isn't the one for me.
I wrote this: https://github.com/Jchase2/simple-pass-manager for that reason. It doesn't even store unencrypted things on disk. I'll still probably keep improving it, like the interface and what not, but I feel like the concept is pretty solid. Granted, it has a very limited feature set. But that's all I need. It doesn't do syncing though. I was thinking about an ocaml pw manager. If I get time.
My only problem with that is that it stores stuff in different files, iirc, which you kind of have to name something recognizable. That is, the file names are exposed, which if you name them, for example, by which site they access, then presumably someone could figure out which sites you use. Of course, since they're all different files, that also adds some security I think.
> 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'm not surprised I butchered it. I'm not a writer by any means. If you look at the few other things I've written, the writing there is just as terrible. Practice makes perfect though I guess.
I guess what I meant was that you are emphasizing that the old-style format is what is the problem here, and that it hasn't been the default for three years now, but the headline makes the scope sound much worse. So saying 1Password as a whole suffers from this flaw is pretty misleading. I agree it's an issue that you weren't warned about the need to migrate to the new format.
No, the problem is that they have a new format but the OLD one is the default. It's incredibly difficult to use OPVault as your keychain format if you aren't on Windows. Even if you are on Windows, you still need to change it every time.
Funny, the title doesn't pop quite as much when it's replaced with the more accurate "1Password Leaks Some Metadata When You Upload Your Keychain to Public Servers".
Metadata is still data? Sure, it's not your password, but the title isn't "1Password Leaks Your Passwords". And it's not just when it's uploaded. It's when anyone has access to your keychain. The primary feature of a password manager is that it is supposed to be resistant to attack.
Passwords are my data in 1Password. If you say to me that 1Password is leaking my data, I'm thinking it leaks my passwords. The headline is misleading.
"1Password Leaks Your Metadata" would be both more accurate and less clickbait.
I disagree. As per the porn example in the article, and many other fathomable situations, metadata in a password manager can be as important, and sometimes more sensitive, than the password itself.
Exactly. People wouldn't care for a politician's password to IloveSexWithHorses.com (unless they like beastiality themselves and can't afford an account of their own).
The fact that he subscribes to such a site though, would be worth gold in expose articles and/or blackmail...
I'm not saying this isn't a significant risk, or shouldn't be treated as such. I'm merely saying that the headline implies that the primary data in 1Password is leaked, when it is not.
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?
It's data about data. So, still data. The title may be a bit sensationalized ("your data" sound like "all your data", but it really is "some of your data"), but it is not false.
> There's a reason it's not called 'data', is my point.
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'?
What about everything that is expected to be private, can be made private, has security implications for not being private, and has no gains for being public other than "it's slightly less expensive"?
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 didn't say anything of the sort. I said metadata isn't data and just because metadata is about you/your data, doesn't mean you own it.
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.
> I've been intentionally vague so as to discuss this in more macro terms
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.
What you've just done to my comment is common on the Internet, but extremely harmful to an intelligent discourse. I wrote what I did all together because each sentence informs and provides context for the others. In isolation, each sentence may carry a different meaning than if they're grouped.
In the future, remember this when you decide to dissect someone's writing.
The sentences are still grouped together immediately above my post - in your post. This isn't some blog post quoting snippets from some other link, or a book quoting sections from another resource. I also strongly disagree that these things are inherently harmful, if that's what you're indeed saying. They can be misused to harmful ends, to be sure - but what would you have me do, ditch quotes entirely? Quote only entire books? Chapters?
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.
I know, but the website address is still data that I input into the application. My point was that it doesn't only leak fluffy metadata that I don't directly input into the application.
... yes, and that's why your claim that "It's false, insofar that it's not the 'data' you give to 1Password." is wrong. Which was my point.
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.
I never said what you're claiming I said, all I said was metadata isn't data insofar that it's not the 'data' you give to 1Password. I never said anything specific was or wasn't data.
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.
Metadata is also not yours in the first place. Data about you or the things you do isn't yours. Does Julian Edelman own the fact that he caught a pass?
How is data stored exclusively on my machines or on my Dropbox account not mine just because it has "meta" as a prefix? It's still data!
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.
Metadata gives information about other data. The length of your password would be metadata rather than data. I'm pretty sure no one really wants that out in public?
Nice thing about 1Password (and other password managers) - password length isn't that important. My HN password is 30 characters, 5 of which are symbols, 5 of which are digits.
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.
In my opinion, the names and URLs in a password manager are data, not metadata.
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).
I don't understand this article at all. My wife and I sync 1Password credentials using an agilekeychain within a shared (between us only) file in our Dropboxes (so we can still have distinct Dropbox logins.
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?!?
>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?
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.
Not defending it but this was always a known, though not massively publicised, issue with the 1password format.
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 :)
That's the hope with the noise. Agile keychain is old and shouldn't be used. I just want them to use OPVault by default and tell users the risks they take with Agile keychain.
I remember those days - using the Safari extension could display login options to a site before a Master Password was entered. It always bothered me but I wasn't tech-savvy and security conscious enough back then to look into it. When that possibility ended, I was relieved - wrongfully, I now see.
Wrote about that back in 2011. Surprised to see it's still an issue, really - I changed formats, but there's no reason for the JS to still work that way.
* 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.
Yea, the general public would not use it. But from the HN standpoint, I think it is a good open source alternative. They are working on version 2.0 and the git repo is reasonably active. (https://github.com/keepassx/keepassx/commits/master)
If by people you mean "Hacker News crowd", I don't know.
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.
You just slandered a security product based on nothing.
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.
Why would I be hoping to generate drama? Your behavior is very confusing.
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.
Yes, I was talking about the HN crowd. I've been using KeepassX for a while now without (m)any usability issues. It's far from perfect, but I believe it is secure (based on the source code), and it works for me, usability-wise.
Nope but KeePassX has an advertising budget of ~$0 so people don't know about it. It is hard enough persuading people to use a password manager already.
I had different issue with their 'secondary vault' feature. Adding additional vaults as your secondary vaults is not just UI thing.
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.
Hello all, I'm the Chief Defender Against the Dark Arts at AgileBits, the makers of 1Password.
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.
I am a bit annoyed. I recently set up syncing between my iPhone and Mac with 1Password, and during the process, nothing in either app prompted me to use the newer format, or informed me about the trade offs that would be made by choosing one or the other.
I understand. And this is pretty much what we are taken to task for in the article.
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.
A big green "this is the best default" with a less prominent option "if you're more advanced and are sure you are using the latest versions of this, use this" seems like a reasonable compromise.
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.
Convenience is great. It's part of why I use 1Password. There is a limit though to convenience. It's not convenient for me if my data is out there. If you aren't willing to automatically push this to users, at least give the users the option. You can outline the pros and cons of each choice.
Also, it's been 3 years since OPVault first came out. How careful can you be?
Well, we've been slower than we (and you) would have liked getting OPVault to different platforms. For sophisticated users, handling the switch should be fine. But we need to make the transition rock solid everyone.
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.
Security is your thing. I think when it comes to protecting your user's data vs inconveniencing them, you should inconvenience them. This will make us trust you more vs creating a new database format almost 3 years ago which fixes some of the security bugs of the old one and expecting only the experts to figure it out. Please make it the default.
If people end up with one set of devices synching an .agilekeychain and on another set of their devices synching an .opvault they may not notice until things have different far apart.
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've been using your software for years now and had no idea about the "new" format. And I don't care about Windows. Please improve how you inform your customers and give me a way to migrate.
And beware - trust is hard to earn, but easy to lose.
So the threat is that if someone hacks Dropbox and gains accesss to your Dropbox they can read which sites you visit?
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 think that the issue is some people don't consider Dropbox a good option to store much of anything unencrypted for sharing... This comes down to Dropbox being a U.S. company, subject to DOJ requests and gag orders, and complying with them, iirc.
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.
Well 1Password is a good solution, expect this meta leaking and I guess U.S. gov can hoover up all that data and see where you are logging in, but I don't know, you just have to weight the options. Actually now that I'm employed and not a student I could easily afford LastPass' yearly fee for mobile, but the LogMeIn buying them thing is a big no-no for me for now. I have to check back in few months or a year and see if LastPass is still usable. Or maybe I'll just try my hand at writing myself a custom solution
I honestly would love to see something resembling "self-hosted" that used dropbox/onedrive/whatever as a common location for the storage, based on keepass. If it weren't for my desire to not be locked into a browser, I'd honestly just use chrome's synchronized passwords.
This is why Keeper uses zero-knowledge encryption. Our CTO, Craig Lurey, wrote more about data leakage here: https://blog.keepersecurity.com/tech/2015/10/23/dont-be-leak... We're assisting any adversely affect customers who are interested in migrating to Keeper and offering 50% off worldwide (except 5 countries). Just shoot a note to sales@keepersecurity.com
I noticed the same issue awhile back, but I didn't make a big deal out of it thinking I had no other choice. Good to know they have another format that limits the leak of metadata. Thanks for the post.
Ouch. 1Password is probably the best usable password manager today; they can do better in a few areas, including this. Another area would be putting blessing/device keys on each device on top of a password, because I don't trust a passphrase alone, and many platforms are getting trusted computing features -- you have a slow process to put a device key on each thing, which is then entangled with your passphrase to decrypt. You could even do a hw token, too. Another area they could improve is network sync -- I don't trust iCloud or Dropbox, and wifi-sync is a pain, so supporting WebDAV or some other open format they could develop would be a lot better.
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.
The part I don't understand about all of this, is how this information becomes public when it's stored in Dropbox? My understanding is unless you create a sharing link for it, it will be privately stored in your Dropbox.
You can also put things in the public folder. No idea why you'd do it though. Perhaps you store your Dropbox password itself in 1Password and therefore you don't have access to it when you are away from your devices, hence the need for a public and open link. (you still need to remember the public link to the keychain though)
It seems content.js at least for me is still hashes of passwords and not the passwords themselves, perhaps you need to open the website to have it be decrypted and saved in content.js?
The only place I've ever used that was inside of Dropbox's web interface, where I'd have to first be logged in. Is it a common use case where it'd truly be public?
Great job finding and writing this. I didn't find your writing to be shit, unlike another user here. I felt it was clear and succinct, without being sensationalist.
Hmm.. reading all the time about hacks and data leaks from password managers. Never heard of one while using Sticky Password. Hope they won't get hacked.
For those using 1Password, this isn't as bad as the headline implies.
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.
Only for remote files, and only if you choose to sync your files to a remote folder which is not icloud ( Dropbox and Folder Sync), it's not used for local data is it, and only for remote data (if you choose to do that) for certain services?
I've played with it a little. I'm curious because it's so cross-platform (I use Mac, Windows 10, iOS, and Windows Phone), yet has a really slick UI like 1Password. It seems about on par with 1Password so far, but like I said I've only used it a little.
I'll try to remember to poke around the data files this week if I get a chance.
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.