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.
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).
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.
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.
> 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.
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.
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'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?
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 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.
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?
> 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.
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.
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.
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.
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.
>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.
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.
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.
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.
* 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)
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.
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.
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?
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.
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 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?
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)
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.
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.
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).
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.
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.
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.
158 comments
[ 4.9 ms ] story [ 218 ms ] threadThat'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.
perhaps you did
> 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.
Yet more proof of time travellers..
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.
http://www.winzip.com/win/en/aes_info.htm
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.
[0]: http://www.passwordstore.org/
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
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
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.
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.
https://support.1password.com/switch-to-opvault/
https://support.1password.com/switch-to-opvault/
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.)
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.
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).
https://support.1password.com/switch-to-opvault/
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.
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.