[activescott]

Seems like 1P took the right steps and is being transparent about the incident. It wasn't even an on their systems - but one of their vendors support systems. A lower quality organization would just conveniently not disclose the incident at all - justifying it by saying something along the lines of nothing was breached, it wasn't even our system. I think we should applaud 1P's transparency here. Or am I missing something?

[greyface-]

> am I missing something?

This comes immediately after 1P's forced transition away from local app with local storage to Web app with cloud storage, and assurances that their security stance and practices would make a breach unlikely. If they had stuck with the old model, a breach would have no chance of impacting users, but now, we're left scratching our heads and speculating about the true extent of the damage.

[zzyzxd]

> If they had stuck with the old model, a breach would have no chance of impacting users, but now, we're left scratching our heads and speculating about the true extent of the damage.

Well, since 1P clients are not open sourced, you always have to trust that they implement their white paper correctly, this is regardless before or after the transition.

Now, if you do trust them, then you should believe when they say that "IdP is only used for authenticate downloads of _encrypted_ secrets and the decryption only happens on device with a local credential", in which case a breach of IdP still would have no chance of impacting users.

I have a lot of rants about this transition, but the storage location of encrypted data is never something I worry about. In the past it was my personal iCloud/Dropbox accounts, now it's my 1Passowrd.com account. Am I missing something?

[greyface-]

> you always have to trust that they implement their white paper correctly

Actually, no - if they implement their whitepaper incorrectly, and I manage to keep my insecurely-encrypted vault blob private, I'm still safe. Bad implementation is only a risk if there is also a data breach. This is defense in depth. Your argument is based on an all-or-nothing model of trust, rather than one where trust can be contextual and partial.

Would you be comfortable uploading your vault somewhere 100% public, rather than behind authentication with iCloud/Dropbox/1P, since it's safely encrypted?

[activescott]

A regular public audit by security firm would help increase confidence in a close source system. In fact, it would help in an open source system too.

[fnordprefect]

I raised exactly this possibility with them when they announced their new model. Their support would not engage with this even as a possibility. Just assertions that everything would be completely secure.

Getting access to this data is the holy grail for attackers - it is preposterous not to have a local-only or "saved on iCloud only" model. Clearly the only reason they removed this ability was the juicy, juicy subscription revenue, which requires them to hold the data.

They may have avoided a breach this time but have they previously been breached? Will they be breached in future? The possibility of each is non-zero.

Needless to say, I'm still using the older version and am planning how to transition once it stops working after an OS update.

[joshspankit]

> juicy, juicy subscription revenue

The irony is that as a user since at least version 3, I would have easily kept paying a yearly subscription fee just for the same local+sync they had before centralizing. It’s clear that most tech businesses need stable recurring revenue in order to keep doing their best work.

They could have probably done an Amanda Palmer-style patreon (donations fund the ability to make all work public) for individuals/families and a straightforward high-cost enterprise subscription and been just as big if not bigger.

[activescott]

Good point. I would have paid too had they just asked.