Hacker News Reader

Comment by Perceptes | Hacker News Reader

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.

View on HN

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.

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.

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.

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/

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

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.

Reply on news.ycombinator.com