The PBKDF2 speed up was 2x, not 4x. Jens was simply wrong about that. The "disputed" speed up comes from an PBKDF2 optimization that is available to the defender as it is to the attacker. 1Password makes use of that optimization. So it gives no advantage to the attacker. It is not a speed up when the defender makes use (as we do) of the same trick.
What versions of 1Password for Windows are you using? The check for updates is over HTTPS. The download is still from a CDN, but the binary is signed (by us). You can examine the trust chain to decide whether it satisfies your requirements.
However, until not so long ago (a few months, I think) you were correct that the 1Password for Windows updater was vulnerable to "evilgrade" attacks.
I would like to thank whoever sent us a Proof of Concept, and I would like to apologize for actually needing the PoC before sufficiently testing my own claims.
But I agree, its a stupid issue. Snowden tells us endpoint security is the problem. So maybe the Windows 1Password client should stop
1) checking for updates over HTTP (no s here!)
2) download the update over HTTP3) execute it with elevated rights without verifying it
This was maybe fixed in the last build from 2013-08-07:
Since they use a CDN to distribute updates, these might still be downloaded over HTTP and still not be verified prior to running.-- Update --
You got to be kidding me. So I upgraded my fake update server with a self-signed certificate (with a wrong CN, no less) and of course, the 1Password client happily accepts it.
Theres some good news, though. They now verify that the downloaded binary is signed (with their own key)!
But since I can control the update server that tells the client what to download, I can just supply the client with an old 1Password build that is still signed but does not implement the strong(isher) scheme in build #333. The installer doesn't complain and what user keeps track of build numbers anyway.