The fact that AgileBit's rep Jeffrey Goldberg is speaking honestly and in plain english about the problem only galvanizes my decision to keep using and recommending their product. It builds trust, as in I trust they will fix the problem and fix it properly.

To be honest, it really isn't much of a vulnerability either. Without this attack, the speed would be 800 Khash/sec. It just speeds it up by a factor of four. If your passphrase is sufficiently good, you're safe.

No, the attack speeds it up by a factor of two (1 bit).

The other factor of two was a known and expected optimization for HMAC that the OCLHashcat developer(s) discovered the hard way. The defenders (1PW's users) may have already been taking advantage of this optimization, so it really doesn't count as an "attack".

Hmm, which is the 1-bit attack you're referring to? I only see one. Also, which is the optimization they might be taking? I don't see any.

One of the factors-of-two comes from computing the first input block of the two SHA's in the HMAC calculation and re-using this. This optimization in HMAC was underdocumented, but it ought to have been used by PBKDF2 implementations.

The other factor-of-two, i.e., the 1-bit attack, comes from skipping the generation of the CBC mode IV and only generating 1 output block (160 bits) of PBKDF2 output for the key and using a later ciphertext block to check the candidate password. This saves the attacker half of the PBKDF2 work factor.

This is a weakness in PBKDF2 when used to generate key material longer than the underlying hash function output length. RFC 2898 explicitly endorses deriving multiple keys in the manner 1Password used it:

    For instance, one might derive a
    set of keys with a single application of a key derivation function,
    rather than derive each key with a separate application of the
    function. The keys in the set would be obtained as substrings of the
    output of the key derivation function. This approach might be
    employed as part of key establishment in a session-oriented protocol.

... without mentioning the fact that some of the derived keys would impose more work factor than others.

I think you mean CBC mode IV, not CTR mode IV. If they'd been using CTR mode, not having the nonce would be a dealbreaker for the attack; no matter what the cracker did, it would never generate the right keystream.

(I don't think using CTR mode would have made a lot of sense and am not saying the use of CBC mode is a design weakness; it isn't.)

D'oh! Thanks, corrected.

And I was just on everyone else for conflating CTR mode nonces and CBC mode IVs...

Ah, yes, you are quite right. It seems like gross negligence on the part of the document to not mention that, given that the work factor is basically exactly what PBKDF2 is used for.