Windows 10: 1Password data leaked for months

Because people make bad judgments and sometimes those mistakes can go unnoticed for years. Did you hear about the Shellshock vulnerability that lurked, hidden away in Unix systems for many years, only for it’s security concerns to be realised in 2014?

But 1Password are not being truthful. They serve the 'Emergency Kit' (which has your unique SRP key inside) over HTTPS. This coupled with your password can be used to get inside your trove of passwords. Not being truthful about what? It doesn’t matter how valuable the payload, being a critical piece of data such as the 1Password ’Emergency Kit’ or not doesn’t void the fact that encryption standards protect your information from being opened and read.

1Password will undoubtedly encrypt its payload before sending it through the internet. The HTTPS protocol encrypts this data even further, the payload experiencing a double encryption, but this double encryption is wholly redundant because most encryption standards are very strong and few computers today have the capacity to break this encryption. Even if they could do so easily, the underlying program must know what it’s looking for, or have at least a vague idea of the structure of which was the original data. This problem is discussed in relation to the idea of Unicity Distance.

I hope this puts the true security of encryption into perspective.

That’s your interpretation. They never proclaimed what had happened was ok. Repeating one of their statements:

They understand that “this was painful for everyone”, describing their mistake as “unacceptable”. Their high modality statements regarding their error exemplifies a sincere apology, and the first person plurals expresses their sense of ownership over the distress that they’ve caused for their users. The ellipsis even epitomises their embracement over the situation, a slight hesitation from revealing the truth, but they do, and they do so openly.

Fair, but your previous remarks on their honesty still intrigues me.

Recall the fate of Samsung’s Galaxy Note 7. Your line fits as a perfect retrospective response to this terrible disaster. Why couldn’t Samsung pre-empt this incident? Because nobody’s perfect, that’s why.

How do they communicate with developers then? Of course they tell them of any changes. In this case there is evidence, directly from Apple (which Apple may choose to release in due course), that Apple told them of the changes in response to an earlier service request. Where then? Evidence? I don’t see a link, I don’t see a quote, I don’t see stats or figures or facts that would indicate as proof that Apple would act to protect a third-party from defilement. If there was some communication it would certainly be robotic, not personal—you don’t know this. Apple’s practises don’t concern us. And Apple doesn’t email developers of an incoming developer certificate expiration. (see my remark below)

True. It certainly is AgileBits’ responsibility to ensure their product is up-to-date and functioning to standards, but as I’ve said, the problem was catalysed from from humanistic error, a mistake. Mistakes can’t be be avoided once they are made, there is only recuperation, and I think they took the best course of action to right their wrong and prevent a similar incident from occurring in future.

Namely, they have “reached out to Apple for help and guidance” over the situation and have subsequently taken the initiative to file an “enhancement request with Apple asking that developers be notified via email of impending distribution certificate or provisioning profile expirations” and additionally include “explanations of repercussions” along with this notice, after they had cleared the problem.

Conveniently, in the same document, “Certificates, Provisioning Profiles, and Expiration Dates: The Perfect Storm”, AgileBits’ recited their ethical stance in software production.

They continue to claim their quality of service in ensuring up-to-date and secure software for their users. Take their word or leave it, that’s your own entitlement.

I want a citation on this. Have you considered that this change was likely made in the interest of enhanced security? Though, if the fact is as true as how you have framed it, my question doesn’t change the fact that the changes had caused inconveniences among users, I understand.


You raise fair points, but my tendency of concern is not on par with your level and I remain unfazed by the faults in the quality of service AgileBits may have delivered in the past on the account that any sufficiently large and experienced business is bound to encounter accidents similar in scale as to what AgileBits have gone through.

You need to put some trust and pliability toward a few things or you’ll only inconvenience your own comfort at the expense of, really, trivial matters. Your information was never at risk. There’s just no mounting evidence to suggest it.

 

Hi, everybody! from AgileBits, the makers of 1Password, here.

I just stumbled upon this discussion searching for something (ain't Google great for falling down rabbit holes?) and just wanted to clarify a few things in case it helps anyone.

There haven't actually been any breaches of 1Password data, though we continue to work hard ourselves and with other parties to identify and fix anything that might pose a risk to 1Password users. I think what ahr10 was thinking of was an older data format in which titles and URLs were not encrypted. That hasn't ever been the case with usernames, passwords, and other sensitive data, but in that case, if someone got your vault somehow (access to your computer, for example), they could find out that you have an item named "Amazon", or with an amazon.com URL, for instance.

More to the point regarding the recent "excitement", in the case of the CloudFlare vulnerability that was discovered, 1Password customers weren't affected because no matter what, data is secured before being encrypted again to be transmitted over SSL/TLS. You can read more details on our blog:

Three layers of encryption

But the short version is that when you use 1Password, AgileBits never has access to your data, regardless of the setup you choose. Even with 1Password.com, your data is encrypted on your device, so all the server ever ends up with is an encrypted blob. And since the Account Key is created locally, your Master Password is only known by you, and neither is ever transmitted, no one — including AgileBits — has the means to decrypt it. You can read more details on how all of this works in our white paper [PDF].
And in the case of macOS preventing 1Password for Mac 6.5.3 from launching, while I can certainly appreciate that some might feel it's "passing the buck" to say that this is a macOS issue, it really it. That's not to say we don't feel terrible that this affected our customers. It sucks that anyone had to manually download an update later in the day to be able to run 1Password again. That just isn't a good experience, and that's why we're resolved to make sure something like this never happens again — for users of any macOS app. You can read the final details of our investigation in this blog post:

PSA for macOS Developers

Opinions may vary, but we feel pretty strongly apps shouldn't simply stop working one day, in the absence of system changes that prevent them from functioning, or a security issue. I personally really enjoy running old school apps and games using VMs and things like DOSbox, and while this isn't mission-critical stuff, I'd be disappointed (to say the least) if I couldn't run a virtualized copy of something like Firewatch in a few years because it "expired".

Anyway, I hope this helps. Whether you're using 1Password or something else, stay safe out there! *Smile