The speedup was apparently 4x, so rather 2 bit, or as the layman would say, only 1/4th the work. But thats not the point. If you can't trust them to deploy a fix to a stupid issue in half a year, why would you trust them to do it in a day should a serious issue arise?

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

   Bonus: you can specify the update URL in the response
   Bonus: you can specify parts of the dialogue shown to the user

2) download the update over HTTP

3) execute it with elevated rights without verifying it

This was maybe fixed in the last build from 2013-08-07:

    Improved security of automatic updates (using https:// when checking for a new version). Reported by David Thiel, iSEC Partners.

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.

[Disclosure: I work for AgileBits, the makers of 1Password.

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.

As stated, the check for updates is finally over HTTPS in the very latest build (333), but you do not verify the certificate in any way. So its essentially HTTP with obfuscation. This allows a malicious network to downgrade clients to build 332, where the check for updates is over plain HTTP and downloaded binaries are not verified.

Can you write a blog post about this? Need to get this information out there. Good job finding this.

I was wrong. The updater in 1Password for Windows 1.0.9.333 is vulnerable to an evilgrade attack. It fails to verify the the trust of the certificate on the (alleged) upgrade server and will accept any old self-signed certificated.

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.

In 2011 they went from 1k to 10k iterations, too. This got done in advance of any known problems, and was a free upgrade.

Also, there were some design issues with their mobile app about 2-3 years ago (essentially, security could fall down to a 4-digit passcode in some cases), but they again fixed that by making the passphrase again the key to security.

In general I've found them nothing but responsive and competent on security issues (as well as better designers and general software engineers than any security company).

More accurately, they did call PBKDF2 once, but PBKDF2 internally calls itself twice if you request a key larger than the hash output size. It "expands" the key by generating two and concatenating. It's a stupid bug, but it's a bug in the spec.

Just to be clear: it's fine to take the output of PBKDF2 and expand it with SHA2. They didn't do that, but that would have been a totally normal design with the same "problematic" performance characteristics.

I'd just as soon pick sha2 as my pbkdf2 hash instead of bolting it on after the fact. That said, I'm not sure what's problematic. Expanding the key with sha2 results in the attacker needing to perform exactly as much work as you. There's no shortcut and no "problem".