Use "App folder" access type instead of "Full Dropbox" | Hacker News Reader

Use "App folder" access type instead of "Full Dropbox"

discussions.agilebits.com

149 pointskobayashi109 comments

I feel sorry for companies these days who have to continually respond kindly (for years in this case) to unreasonable customer demands via forums/facebook even when they've clearly stated why things are configured the way they are and changing that will break functionality for tens of thousands of people.

Some companies after a while just need to start following the Wendy's Twitter account model where they start just telling folks like it is after they've shown they aren't going to be reasonable.

I feel bad for users who have to deal with supposedly-security minded companies who cite weak, historical reasons for not doing the right thing now.

Companies who ignore the actual solutions proposed to them, and instead attack a straw-man. Claiming they're being asked to make backwards incompatible changes for all existing users, instead of providing an an opt-in alternative for users who actually care about their security.

Companies whose culture is so inept that they blindly commit the most basic of engineering fallacies: Rejecting solutions on the basis of minor flaws, while defending a incumbent solution with massive flaws, simply because it is incumbent.

The users don't have to deal with it. No one forces you to use 1Password. They've been asked and stated their position and don't owe anyone anything else. If the folks in the thread (or here for that matter) don't like the answers, don't use the product. Pretty simple.

Are we allowed to say why we don't like what they are doing?

Are we allowed to tell other people why?

Then what is the problem??

Sure, complain away! This is the Internet after all. My problem is the fake pity for users who make the conscious choice to use the problem despite - or regardless of - it's faults. If you don't like how AgileBits handles Dropbox permissions, either don't give it Dropbox permission or don't use 1Password. Complain, sure, but don't pity users for the sake of hyperbole. I read the original post in this thread as genuine pity for AgileBits, which I share - they get to make the application they choose, and users may or may not use it. But hyperbolic pity for the users? That's my problem.

Without users your product is nothing regardless of how great your product is. You are nothing without your users. You are what you are because of your users. Many companies forget that Agilebit is one of them. Throwing your users under the bus just because you can is not acceptable.

As someone done Dropbox integration for many of my clients, I know how easy it is to implement app folders.

I know it and you know it. We all know what kind of game agilebit is playing here.

I've never implemented Dropbox in an app, so I don't know. But what you don't know is that the people who message AgileBits on their website are even customers in the first place. And even if they are, which I'll concede because I don't care, there were a handful of them. Presumably this is a handful out of thousands? Millions? If it mattered to more people, more people would complain. That was my point.

They addressed the ease of implementation, and have a valid point - it breaks backwards compatibility. That is something I do know about, and it's a terrible thing to do. Yes, they could write a migration path. Yes, they could write all the documentation in the world to go with the migration path. But, yes, it will cause their existing customers - who aren't complaining, save a handful - pain, since the app will stop working as expected, even if only briefly. And that still doesn't address the fact that AgileBits gets to make the app they want to make, and we have the choice to use it or not.

The ease of implementation was never their rationale not to, and even was acknowledged in the thread. And my primary point was that they're only accountable to users as far as they can keep them, and have the freedom to make the application they want.

Its very convenient for them to use backward compatibility as an excuse. but in reality its simply not true. they can implement the change totally transparent to the user. have seen people do crazy things with dropbox integration in on 2 day hackathan's. in this case of moving the storage to app folder, shouldn't take more than coupe of weeks for an junior engineer. only things is whether you are willing to do it nor not. Apparently agile bits are not willing to do. (who would't like to access entire dropbox folder of the users ;) )

Keep in mind that, since dropbox did not have app folder concept initially, many companies used to have access to entire dropbox then moved to app folder model later. they did not break backward compatibility and they didn't make the excuses.

Are users' Dropbox creds (password, optional 2FA) in 1Password?

Do you see AgileBits' point about that?

If your own creds are able to use more than the app folder, and if your threat is Agile Bits binary, the 1P app folder permissions will do nothing, the evil binary will just use your full creds.

Sounds like clamoring for them to reduce a bunch of use cases in service of security theater.

AgileBits is doing the wrong thing here.

Dropbox full access is stored on their servers and it's in clear text. Dropbox regular login/password is also stored on their servers, but encrypted via a remote master key.

If AgileBits is compromised, they can access all your DropBox files. Attackers still can't access regular login/password because of the lack of master keys.

How is Dropbox access stored on AgileBit servers? I buy an app license. I then set up a vault in a Dropbox folder just like a local folder. I use 1Password to access that vault. Same goes for the iOS app. If the worry is iOS, one should assume that every iOS app company that uses Dropbox has a copy of your Dropbox creds on their server, correct?

It is my understanding that at no point, does AgileBits store my Dropbox creds. It also does not store my 1Password vault.

Almost everything you just said is incorrect.

You don't even enter your dropbox password into the app unless you're storing it as a credential, they present an authentication dialogue for the dropbox API just like all other third-party apps accessing Dropbox and store the OAuth key on the client. Not the server. That's why you have to re-authenticate with dropbox on every device you want to set up 1Password sync.

I stand corrected. There is no security - or security added - issue.

Okay, but this still makes device able to access my entire Dropbox, which is insane!

One person's "thing that is broken for weak, historical reasons" is another's "pebble on the inevitable mountain of technical debt."

Complexity scales super-linearly on number of features. Solutions aren't the hard part. Implementations are.

> and changing that will break functionality for tens of thousands of people.

This particular request explains why this wouldn't be the case.

It doesn't sound particularly easy, because the app would then have to support two modes - the new secure mode, and a legacy mode for backwards compatibility to avoid breaking users. There certainly would be an additional maintenance burden.

But it is disingenuous to claim that it is impossible to do so.

Your characterizations are incorrect, or as some might say, 'disingenuous'.

AgileBits does not claim it's impossible to do so. To quote:

"This is not to say it's impossible, but it requires much more careful planning and consideration than changing the permission request in the application."

They also note that 'the new secure mode' would break functionality for "many customers", due to a design choice (or flaw) in the Dropbox API:

"But even if we were able to work around many of those complications and used the Dropbox API to limit permissions and use a specific app folder, there's still at least one major issue, which (as Khad explained to you a few years ago) is that Dropbox API doesn't allow sharing folders between different Dropbox accounts. That would prevent sharing a 1Password vault with others via Dropbox, which is a feature that many customers love and rely on."

Claiming that this 'wouldn't be the case' is a misleading characterization. In actuality, they would have to support two modes - a reduced-functionality 'secure' mode, and a full-functionality 'legacy' mode. While it may be distasteful that users shares password vaults using Dropbox, they have clearly chosen to continue supporting that use case.

1Password offers a paid product that competes with the usually-free Dropbox-based sharing solution. Their paid product is far more secure than the shared-Dropbox method, with both per-vault and per-device encryption keys. It offers no compromises in functionality and offers what some would consider an increase in security for shared-vault users over the 'legacy' Dropbox model discussed herein. It uses a cloud storage service other than Dropbox, but that's no more a dealbreaker than Dropbox itself would be.

So with 1Password having already implemented both "the new secure mode" (paid) and "a legacy mode for backwards compatibility" (dropbox), they clearly have already accepted the additional maintenance burden of the increased security requirements of their 'new' method.

Please identify the evidence you see supporting your claim that it is impossible, in light of their words and actions to the contrary.

> Please identify the evidence you see supporting your claim that it is impossible, in light of their words and actions to the contrary.

I'd even just like to see evidence that is is difficult to do. I mean, I can see how it's more work than doing nothing, but I find it hard to imagine it's all that challenging.

> Please identify the evidence you see supporting your claim that it is impossible...

Huh? I claimed no such thing. I said "But it is disingenuous to claim that it is impossible to do so", which means exactly the opposite of what you seem to think that I claimed.

If I didn't know HN better, I'd think this was a satirical comment. 1Password is a security product, and they are intentionally not addressing a legitimate security concern because they don't think it's worth spending the effort creating a migration path for the way it works now to a better way. Yes, there are cases where customers angrily demand things that are unreasonable, but this is definitely not such a case, and blindly defending a company's bad actions because you feel sorry for the company is tiring. A company is not a person. It is not a moral virtue. Users pay money for this product, and they do not owe anything further to the company. The company should deliver the best product it can.

Every security product needs to make trade-offs between confidentiality and availability. Addressing all "legitimate security (meaning confidentiality) concerns" results in the proverbial turned-off computer under a mountain with a Marine standing guard. Agilebits have chosen a trade-off which maximizes their users' availability while minimizing Agilebits' best assessment of their users' potential for unacceptable loss of confidentiality, in service of delivering the best product that they can.

Now, you may disagree with Agilebits' methods of assessing those qualities or the particular trade-off they're choosing to make here, but you can't claim "security" in the abstract to justify a change without articulating its costs and benefits in more-concrete terms.

What is the availability trade off you're referring to? I don't see a downside to migrating to more limited permissions for the user. Agilebits just has to do the work to make it happen.

AIUI, under the proposed system, Agilebits would have to do permissions prompting every time the user created a vault in Dropbox, which adds friction to the process (makes it less available). They would also need to provide a reasonable migration path for existing users, which, for those who encountered problems, would result in them not having access to existing vaults or the vaults not updating correctly (loss of availability).

And then dollars to donuts, after all that work, users are just storing their own full Dropbox creds inside the same evil 1Password app you're worrying about. What was the point of the theater?

I don't know the details there, but I'd be surprised if the user was storing their Dropbox credentials in 1Password configuration. I'd expect it uses OAuth to create a token that provides 1Password with scoped access.

But how does the user log into dropbox when they go to the website? They probably store those generated credentials within the 1password vault.

which is encrypted.

If 1password has been injected with malicious code, whoever has done so will have all your encrypted credentials the next time you unlock your vault, including presumably your full Dropbox creds.

(Caveat: I use Keepass2Android, which ironically DOES support limiting access to the Apps folder in Dropbox.)

Keepass follows best practices more than 1Password.

http://mostvulnerable.com/

I don't think you can share Dropbox app folders between multiple Dropbox accounts, which would remove the capability for teams to use 1Password + Dropbox to securely manage shared passwords.

Incidentally, these sorts of access concerns are why I use KeePass over Dropbox instead of 1Password or other password managers with a hosted component.

I have 1Password vaults in 3 different shared folders in addition to the default 1Password app folder. I use these shared folders to share vaults and passwords with my husband, my sister, and my parents. When I update our bank password, for example, I don't have to update it twice. It is stored in the vault that my husband and I share. This is critical to my use of 1Password.

I would much rather have this scenario (and give 1Password access to my full Dropbox) vs having all of my data on AgileBits servers and paying for an account for families or yearly for each individual. If 1Password went to requiring vaults to be in a specific, app-permissed folder, it would break my workflows completely.

Is it a legitimate security concern, beyond the unlikely case where you don't have your Dropbox credentials in 1P? What scenario does it defend against?

Full disclosure: I'm a satisfied 1P user and don't really care about what kind of Dropbox access they use, although I'm open to persuasion on the second part.

Can you walk me through your thinking on the first point? I use 1Pass but not Dropbox Sync with it, my DB credentials are stored in 1Pass.

Wouldn't the synced 1Pass passwords in DB be in an encrypted blob? I would assume that if someone compromised my DB password and got full access, they wouldn't be able to access the 1Pass passwords without my 1Pass Master Password. Is that not the case?

That is the case, but I think you're approaching it from the wrong angle.

The dispute is about 1P's ongoing access to DB after you grant it permission to connect. The claim is that giving 1P full access is an increased risk.

The only way 1P's access to DB is a risk at all is if someone got ahold of 1P's access token. The only way to do that (at least on iOS) would be to exploit 1P somehow. But every time 1P runs, I authenticate, which would give exploit code access to all my passwords, including my DB password.

I don't see a scenario where an attacker is able to access 1P's token but not able to access my DB password.

This makes sense, thanks for the clarification.

> to unreasonable customer demands

i think i agree with this.. i mean, who stores unencrypted data in Dropbox anyway?

I think the real problem here would be people uploading unencrypted 'sensitive' data to Dropbox in the first place.

Asking AgileBit to NOT ask for entire dropbox storage is not a UNREASONABLE request.

Looks like AgileBit is really really nosy about what users has stored in their dropbox. and just hate to lose the luxury to access every data stored by user.

Read the Pilor's (from AgileBit) response. she gives a link to article which talks about "How to sync 1Password with Dropbox" but she lies that the article details "Why 1Password needs full access".

I'm trying to understand this comment in the post:

As it stands now, if you are compromised, whether through a hack, state action, or even a disgruntled employee, you will expose the full contents of tens of thousands of Dropboxes, a monumental security nightmare for your company.

Does 1Password have a web-based interface where you authenticate against Dropbox and it stores the credentials server-side? I didn't think it did but I'm not super familiar with 1Password.

Otherwise the only attack vector is a compromised 1Password application, right? Not saying that's impossible, but if you are opening scenarios to that line of attack then many more worse things could happen even if the app didn't have outright Dropbox credentials.

I'm confused too. To my knowledge Dropbox credentials are only ever stored on the client. If the 1Password client is compromised (presumably meaning the installer download is hijacked like what happened to Transmission), your Dropbox files being compromised will be the least of your worries.

I agree that a compromised 1Password application poses a much bigger threat than Dropbox access. But instead of a malicious attack, I would argue that it's more important to protect against a bug or faulty code.

Based on 1Password's response, it sounds like the app has to locate the password file based on a settings file, which could be a little fragile. A flaw in the code logic could accidentally modify other files unintentionally.

As an example, there was once a bug in Steam on Linux that force-deleted root because a path variable wasn't checked to ensure it wasn't empty.

The evil 1Password binary can just use your own Dropbox creds you presumably store in 1Password. The app permissions would be security theater.

No. As you would expect each 1Password client authenticates with Dropbox. There is no server side storage of Dropbox credentials and the ranting user is mostly clueless.

Perhaps I'm a bit dense here, but in the proposed attack scenario, couldn't the compromised 1Password application just send all passwords to a malicious server when the vault is unlocked - and assuming you have your Dropbox credentials in your 1Password log in and take your files anyways?

I think the files would still be in the Dropbox Trash. But yeah - think the first part could happen.

If you have 2FA enabled on your Dropbox (and probably your email too), then taking just your credentials won't give the attacker access.

Also, an attacker logging in to your Dropbox would leave a trace in your activity log.

You could still be compromised in this situation if you use 1Password to store your 2FA codes.

Sure, there are scenarios where limited permissions won't make a difference, but there are also scenarios where it will make a difference, and that's what matters.

Of course, it's up to 1Password to decide whether those scenarios are a high priority or not.

edit: 1Password, not Dropbox

A compromised 1Password on a Mac could just read the contents of ~/Dropbox and fling it at a remote server, bypassing any Dropbox API perms entirely, even if the user of the system was using non-Dropbox syncing for their 1Password Vault.

Not that the problem is localized to 1Password: any non-sandboxed app could do that, given the default system configuration.

A compromised 1Password application on a Mac can read a lot more than ~/Dropbox. I'm not sure why this problem is specific to Dropbox? Nor why changing the permission would materially change anything? Am I missing something?

Nope, your understanding is correct. That's why I'm not very concerned about the lack of "App folder" access strategies.

OT: To be honest, that was something that always bugged me about password managers, particularly cloud-based ones. I'm not doubting the added security, but isn't it offset by adding another link in the chain with the power to compromise - and even lock you out if it's the only place you store the passwords - of all your accounts?

That's the nice thing about being able to export an encrypted 1Password database for backup. They even store periodic backups for you with the Mac client at least.

For non-enterprise users, Dropbox's encryption is basically meaningless. If you have sensitive information you want to store in Dropbox, Google Cloud, iCloud, etc., I'd recommend using something like Cryptomator: https://cryptomator.org/ to encrypt files on the client side before uploading to "the cloud". It's open source for security experts to look through it and free for desktop OSs. I think they just charge something like 5 bucks for the iOS and Android apps.

For alternatives to the popular cloud services for the privacy conscious, there's a good list of open source projects and products on https://www.privacytools.io

I second Cryptomator. I used it to make an encrypted "File Cabinet" for important documents that I want on Dropbox.

It is so simple, I actually used to it show my mom show to set up an encrypted folder on a flash drive of important information she wanted to store in a safety deposit box.

This is not an all or nothing issue. For example, if you store sensitive videos, but rely on Dropbox's ability to transcode and preview the video in a web browser, then something like Cryptomater would not make sense. Encrypting on wire/at rest is the best you can do unless you run the transcoding yourself.

Dropbox could support both modes, but the company has obviously made a decision to prioritize one over the other (at least for now).

> The alternative solutions aren't great. $36 a year to store a couple megabytes of data is outlandish. If you'd like to transition us to this from Dropbox, the price must be drastically reduced.

I've found AgileBits a bit weird in some of the decisions. It's clear that selling a password manager for $65 is no longer working well for the company, and so the subscriptions were introduced (IIRC, shared vaults exist only in the subscription). But as the OP says in the forum post, the subscription prices are quite high from a value standpoint when people have been using Dropbox or iCloud or something else all along. I've seen that AgileBits is also a bit slow to learn from customer feedback (like the MAS-only fiasco a few years ago). As more and more apps move toward a subscription model than a one-time pay-for-a-major-version model, I foresee more customer backlash on prices.

Edit: This backlash against subscription has already happened on the app store for Facetune and Infuse, to name two apps.

You can share 1Password vaults with any kind of shared storage: Dropbox, Perforce, NFS, whatever. AFAICT the only thing 1Password.com provides is a nice, in-band UI for doing so.

It also provides access controls in a way that other sharing mechanisms do not. Most of these are not available on the Family sharing plan (which I’m using for my family), but the enterprise version is comparable with what LastPass enterprise offers.

lastpass is still $12 and on Android it is AMAZING. I just sign in with my finger and it will fill out all the passwords in apps. I got my first phone with a finger print reader (LG V20) and I was up and running signed in with every account in 1/4 of the time.

I still have my bank account memorized but other then that lastpass has been awesome for me for close to 5 years.

And did you know that Lastpass for mobile is now free? I use Lastpass too and love it. Was also paying $12 but this was a nice little gift. You have to go into your prefs and switch off automatic payments if you want to switch to a free account.

https://blog.lastpass.com/2016/11/get-lastpass-everywhere-mu...

I'll still pay because it is worth the $1 a month and keep it going.

How is this related to the issue reported and how does it 'make it clear' selling a password manager is working well for the company? This particular user seems to believe that if 1Password turned malicious, their Dropbox permissions would somehow protect them. Which they won't, at all.

I quoted the text from the user's post in my comment:

> The alternative solutions aren't great. $36 a year to store a couple megabytes of data is outlandish. If you'd like to transition us to this from Dropbox, the price must be drastically reduced.

That $36 is a subscription price for the alternative, which the author mentioned as "outlandish" in that forum post.

And what's wrong in saying that the company moved to subscriptions because the $65 one time sale is not working out very well? One the company's website, the pricing page lists only the subscriptions prominently. One would have to either know that there is a standalone license or scroll down to the bottom of the page to find out that a standalone license exists. For a sale page, it clearly uses a dark pattern to make it seem like subscription is the only way there. Even the page name in the URL is "sign-up".

Because you seem to think that a) the user's complaint makes sense and b) the reason they don't 'fix' it is because they want to make the user pay $36/yr. Both of these are obviously inaccurate.

As someone who buys this for every employee at his organization, I couldn't disagree more.

It's a huge deal that I can control who shares and sees what vault, turn off an employee's access as soon as they are leaving the company, revoke tokens, etc.

Before this we were using Dropbox and it was a nightmare. Credentials for a bunch of things were mixed up in the wrong vaults, far more duplication, revoking access was more of a pain, etc.

1Password for a family sharing may not be worth it, maybe not even for a small 5 person shop with a very stable set of employees who are all savvy. But with 25 or so people with varying level of technical expertise and actually critical information being shared, 1Password's subscription is a godsend.

I have 1Password for family sharing (the online service), and it’s totally worth it. I’ve been a 1Password user since the AgileBits blog was the “Switcher’s Blog” and have bought every version they have released for Mac and iOS because it does exactly what they say it does, and they review their security pretty regularly. (It helps that I’ve met people on the team, but that‘s a secondary matter.)

For US$48 per year (I have the launch special, but it saves me $12/year), I have four people currently signed up (I could add three more; again, the launch special gives me two extra) where we can share passwords. I also have any major version of the software released now for any platform.

More importantly, I have been able to get my parents on 1Password reliably in a way that if they are incapacitated, my brother or I can use their accounts to make sure bills are paid when they should be (at least, that will happen when we have all of their accounts added to 1Password, but that’s a relatively small thing now). This is important because neither I nor my brother live near my parents (I’m in a different country). The software versions? Pretty important: I’m on Mac and iOS; my brother is on Mac and Android; my mom is on Windows and iOS; and my dad is on Windows and iOS and Android. Keeping those up-to-date with major versions would eventually get more expensive than the peace-of-mind that I have now.

LastPass does all of this cheaper at scale for companies ($2.40–$4/user/month) than 1Password ($4–$11/user/month) but the UX for LastPass is abysmal (although it does have a dedicated Linux client for those who need that)…and I honestly don’t trust LogMeIn at all. The other one that I have any opinions about is Dashlane, and it’s second/third-hand that it’s pretty good software (I haven’t used it because I’ve integrated 1Password in my workflow so deeply).

Yes, 1Password for families is worth every penny I pay.

If you're security minded, don't use Dropbox for syncing (or at all - it's kind of a mediocre service these days).

Annoyingly, 1Password don't support syncing opvaults from an arbitrary location on the filesystem to allow you to use Syncthing. It's literally the only reason I still have a dropbox account.

I think it does? https://support.1password.com/local-folder/

I use that for one of my laptops that doesn't use dropbox and just set the folder to be the folder of the sync service I'm using on it.

It does... That's how I've been doing my syncing.

All my 1Password vaults are kept in my ownCloud account. Even works fine on Android where I use an app called FolderSync to keep my vault synchronized on my phone and have added it to the 1Password Android app.

i was trying this too. I've setup my own cloud and i only wanted local lan sync but i'm not able to sync to my 1password android.

may i ask: on the android app, where are you keeping the opvault file? when i pointed the android app folder sync to the opvault folder downloaded to my android phone, it said 'no vault found'. are you using the old keychain file format?

thanks kindly

The oauth tokens are stored on the client.

In order to exploit the suggested privilege escalation, you would need to exploit the client to feed you the oauth code. If you are exploiting the 1password client, you can do ANYTHING (including grabbing passwords after you unencrypt, reading filesystem, popping up a PWNED dialog). I don't think this effort should be urgent for 1password.

This recommendation doesn't make me feel meaningfully safer

(unless 1password has some clever process jailing inside their code to isolate the decryption component from the cloud component)

The point is that it would break features for many users in exchange for security theater.

Limiting the access of Dropbox is all well and great except that it breaks sharing, which many people use, in exchange you simply move the files to another folder on the same Dropbox which effectively does nothing.

Slightly off topic, but Who stores senstive files unencrypted in Dropbox anyways?

I do. I keep my backup 2-factor authentication code for gmail in my Dropbox folder.

Access to my Dropbox account would compromise my gmail account (and vice versa, since I keep my backup Dropbox 2-factors in Google Drive). I consider these two accounts my most sensitive/critical accounts for that reason. Could I encrypt the files in Dropbox? Sure. But that would make it more difficult to get to those backup keys (I might be reading them off a text file from the Dropbox app on my phone, for instance).

Has this happened often? No. Like, literally once. But it has happened, and I need to be able to recover my backup 2-factor codes.

If they are your most critical accounts, why are you doubling the attack surface by allowing a compromise of either to compromise both?

I do. I keep my backup 2-factor authentication code for gmail in my Dropbox folder.

Why not use a physical 2nd factor such as a U2F key?

This is the whole purpose of using a password manager. 1Password is capable of providing OTP codes instead of something like Google Auth. Obviously this makes 1Password a single point of failure, but that's true of password managers in general anyways since people usually put all of their sensitive things into them. At least with 1Password you can isolate items into vaults.

Just curious what the general consensus of 1Password is here on HN? I am especially interested to hear from people that are actually using/paying for the cloud hosting (their servers).

Trusting someone else with your passwords is playing with fire.

The alternative is trusting ME with all those passwords, which is far more dangerous. Because I'm neither going to do a good job of creating passwords, nor of remembering them, so I'm going to end up using the same shitty password on every site I care about.

Well, whose fault is that? I can tell you how to do it right, but it sounds like you're limiting yourself. If you prefer to do it wrong, feel free.

Per https://1password.com/files/1Password%20for%20Teams%20White%..., using 1Password's own sync service doesn't mean trusting the company with the data. The client encrypts it and the server/sync platform is untrusted.

I use 1P for Teams and have a small personal account and have been very happy.

I've been using it for a number of year and love it. Very rarely do i have any complications with it. My biggest complaint is the number of other apps that don't integrate the password manager into their logins so i have to go into 1p separately to get the password—its a minor hassle, but annoying when all you want to do is log into some rarely-used app.

Have been using it for years. Tried Dashlane, Keepass, LastPass, but it's still by far the best at what it does, especially on iOS and macOS. The new web solution is quite neat too.

I have the non-cloud version, works fine. The most annoying part is that the license/version scheme is, in my opinion, too complex. I can never exactly tell if I have the latest version and if I need to upgrade (which costs $$). It seems silly to have to consider what machines/operating systems I'm using when picking a license -- especially when a key feature is cross platform/device syncing.

I would rate the browser extensions 3.5/5 -- sometimes has trouble when there are multiple browser windows and I can't exactly figure out what the "timeout" period is before I have to enter my cumbersome master password again.

I would rate the Android app 4/5 -- it has a feature to use a PIN instead of my full master password, which is fine for my usage, but that feature never seems to work.

Overall, it works fine about 90% of the time. I feel like I've gotten my monies worth. My password habits are better than before using it. I think the software could be improved and I am slightly hesitant about the companies recent push for cloud hosting (which I will never use).

I've been on 1Password for about 3 years, using their cloud hosting for 6 months. Nothing but good things to say about them really... the cloud version removed a layer of occasional annoyance with syncing, the iPhone app with fingerprint access is excellent. The price is fairly high, but I really value a security product that's well thought out and easy to use.

I can't offer consensus, but I can relate my experience. I recently purchased 1Password for Teams based on previous discussions of its design merits relative to tools like PasswordSafe and KeePass (both of which I've used in the past), and I've deployed it across Windows, macOS, and iOS clients and used it with Firefox, Safari, and Chrome, in addition to making regular use of the in-browser web app (which is required in order to manage the team). From the user's perspective, the macOS and iOS clients work the best in that they support all of the 1Password client-side features (adding/editing custom fields being the one I use the most). The macOS version of the browser plugin has a great UI, in that one can quickly access/edit the different credential record fields via its pop-up window.

Neither Windows client nor the Windows browser plugin seems to be as flexible or as polished. Until very recently it wasn't possible to add custom fields (one had to log into 1Password via the in-browser client or use the macOS/iOS client to do things like add a TOTP credential), and the browser plugin's UI is slow and more difficult to use compared to the macOS version. While the Windows client comes packaged as an MSI, I believe that it only supports per-user installs, which prevented me from deploying it using our enterprise configuration management system. Ultimately, it seems like the Windows client and browser plugin aren't supported as well as the macOS/iOS versions, which has ended up slowing our adoption of the software as most of our users run Windows (I'm getting ready to transition away from macOS myself).

The team management features of 1Password work well, but one can only access them via the in-browser web app as neither the client nor the browser plugin provide access to those features. So far I haven't run into any synchronization problems, and that includes using it in some out-of-the-way places with poor network connectivity (high latency/high packet loss/low bandwidth).

Because I was using KeePass, I could not use 1Password's built-in migration tool. Their third-party migration tool (which I grabbed from their GitHub repo) worked smoothly.

Overall, 1Password for Teams works better than the mix of KeePass and ownCloud I was using before (not to mention the questionable third-party ports of KeePass to iOS/Android or the fact that KeePass did not work at all when run under Mono on macOS). Despite the limitations and relatively poor performance of their Windows offerings (my biggest issues with the product), I will likely renew our subscription this year.

It's very nice, particularly if you live in the Apple ecosystem where KeePass clients are complete crap.

I avoid the 1Password.com cloud hosting stuff because it slightly expands the threat model in exchange for web access to my passwords on public/stranger's computers, something I view as an anti-feature.

I've been using the non-cloud version for two years now. Works almost[0] perfectly on Linux with wine as well!

0.Browser integration works but the auto-submit feature doesn't.

I have used 1Password on Mac and iOS since 2010. It has been completely effortless and the browser plugins are excellent. There is nothing negative that I can come up with except perhaps the price (which is a minor point, because the last major version updates were free).

I was opposed to the subscription-based pricing. However, my wife moved to an employer where it's not possible to install 3rd party software. Since 1Password Anywhere is now defunct [1], we decided to take a family subscription so that she can use the web interface at work.

Their subscription version also works fine - I didn't notice any significant differences in my day to day use, except that sharing has become much simpler.

[1] https://discussions.agilebits.com/discussion/63045/moving-be...

Agilebits position on PGP signing 1Password.

"Now there certainly are some geek creed we could get from building PGP/GnuPG signatures files, and we might do it. But I'm doubtful that it actually would provide a meaningful improvement in security. On the whole, we try to avoid "security theater" even if it is of the geeky sort"

* They are a bigger target to a watering hole attack than Transmission BT.

* They think authenticating your downloaded is "security theater".

* They are #2 on http://mostvulnerable.com

+1 for security theater. If 1Pass app is compromised, you're compromised - period. Even with app permissions, does it not still have file system access? I don't see how this change would prevent it from accessing all your Dropbox files anyway. Also, since Dropbox uses an exploit to gain permissions, I'd say we're placing blame in entirely the wrong place here. On the other hand, the 1Pass folks in that thread are giving all the wrong reasons. "We won't do this because it's hard," is very different from, "we won't do this because it offers no benefit in any scenario." Users who are security conscious aren't using Dropbox to sync their password vaults.

I have been using KeePass for some years. It's open source and works on basically every platforms there is.

What is the advantage of 1password compared to the rest of the lot? I keep seeing the name in articles so it must be popular, but I associate it with passwords stored in the cloud which sounds insane to me.

Your association isn't really accurate. 1Password's storage model is basically the same as KeePass, your passwords are stored in encrypted blobs that are not decryptable without your master password, which is never sent over the network even if you use their completely optional cloud storage and web interface. If you don't want to trust them with even your encrypted blobs, it also supports sync via Dropbox or iCloud, or over wifi to your phone/tablet, or just to a plain folder.

As far as advantages, I'd say that 1Password is a very slick and well-designed password manager that focuses on covering a particular common case - someone with a Mac, an iPhone/Android device and possibly a Windows PC who wants to sync their passwords between those devices and fill passwords in their browsers. It offers first-party supported browser extensions and handles conflicting sync changes well, which were two major pain points for me when I used KeePass.

If you're happy with KeePass, there's not really a compelling reason to switch. If you fit their target audience and want something with better sync/browser integration and/or a better Mac client, I think it's a compelling alternative.

If One Password was compromised wouldn't an attacker have your DropBox credentials anyway?

Would 1Password on desktop work even with an App folder?

Yay, keychain

As a customer of 1Password, I will never move my password files into their cloud.

Encryption is meant to provide security in a hostile environment (the cloud in this instance). So, as long as you're using proper encryption and long enough pass phrases to make brute-forcing nearly impossible, storing info on the cloud should be okay.

Well, I prefer to store the password files on Dropbox because Dropbox guys are unlikely to know how the files are encrypted. That actually makes brute-forcing a little bit more difficult.

Why not? 1Password is built on the assumption that your vault could be copied by an adversary at any time, a 1Password account is even theoretically more secure because in addition to needing your master password they also need your account key which can only be retrieved from an existing device (or your recovery toolkit that you promptly printed and stored in a fire safe, right?).

I've had this very same thought, really needs addressing. Not sure why this is such a hard thing to achieve tbh

So happy I replaced 1Password with a 600 line shell script: https://www.passwordstore.org

http://passwordlive.github.io/

This is a deterministic password manager, which is not a very good idea. https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

Reply on news.ycombinator.com