Hacker News Reader

Comment by res0nat0r | Hacker News Reader

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.

View on HN

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.

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.

> 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.

> 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".

Reply on news.ycombinator.com