3 ms·

As a counterexample: I've been using dropbox sync for years, 1000+ passwords, only ever had one problem due to a conflict ("lost" password I made on mobile, re

by Groxx 8y ago

As a counterexample: I've been using dropbox sync for years, 1000+ passwords, only ever had one problem due to a conflict ("lost" password I made on mobile, resolved by picking the right conflict-file in dropbox). That said, I refuse to use cloud-stored browser-accessed password managers, and it's looking more and more like they're pushing for that to be the only option. Not there yet, but oh boy are they pushing it down into the deepest corners of the website.

bwoodruff 8y ago
> I've been using dropbox sync for years > That said, I refuse to use cloud-stored browser-accessed password managers There seems to be a disconnect here? Ben Woodruff AgileBits
- Groxx 8y ago
  Not even slightly. Encrypted at rest -> who cares where it is stored or how it's synced. Desktop app: I can stop updating, firewall the app, use offline, airgap a computer, I have many options for reducing my attack surface. Website: I have literally no way of locking down a version, possible-but-I-haven't-seen-it to be notified of changes (but likely not block them), and it would be rather trivial for the site to ship new JS that simply uploads your password once entered. Not that I think you are. I assume you'll approach that with the same level of care as you've given your apps (which has been fantastic). But I do think that you're a gigantic payout if someone successfully breaks in. Why should I throw my eggs into such a large, internet-connected basket? --- For comparison, injecting a malicious update into the apps to do the equivalent of a trivial, invisible JS change means: 1) getting a change into the binary (maybe they brought their own tho), 2) breaking into your app-signing system which is hopefully among your most-secure locations[1], 3) distributing the app to both customers and employees with a visible update notification, and 4) not getting caught before I download it. For each app. Websites are far, far easier to take control of. [1]: I'm not aware of any server-side security-oriented frontend-web stack which would mitigate this in the slightest. I hope there is though! I'd love to read up on it if anyone knows of one.

by Groxx 8y ago

bwoodruff 8y ago

> I've been using dropbox sync for years > That said, I refuse to use cloud-stored browser-accessed password managers There seems to be a disconnect here? Ben Woodruff AgileBits

Groxx 8y ago
Not even slightly. Encrypted at rest -> who cares where it is stored or how it's synced. Desktop app: I can stop updating, firewall the app, use offline, airgap a computer, I have many options for reducing my attack surface. Website: I have literally no way of locking down a version, possible-but-I-haven't-seen-it to be notified of changes (but likely not block them), and it would be rather trivial for the site to ship new JS that simply uploads your password once entered. Not that I think you are. I assume you'll approach that with the same level of care as you've given your apps (which has been fantastic). But I do think that you're a gigantic payout if someone successfully breaks in. Why should I throw my eggs into such a large, internet-connected basket? --- For comparison, injecting a malicious update into the apps to do the equivalent of a trivial, invisible JS change means: 1) getting a change into the binary (maybe they brought their own tho), 2) breaking into your app-signing system which is hopefully among your most-secure locations[1], 3) distributing the app to both customers and employees with a visible update notification, and 4) not getting caught before I download it. For each app. Websites are far, far easier to take control of. [1]: I'm not aware of any server-side security-oriented frontend-web stack which would mitigate this in the slightest. I hope there is though! I'd love to read up on it if anyone knows of one.