I really wish I knew more technical details of how they have used the PBKDF, because the more I think of it the more I think they must have done something really bizarre to be susceptible to this attack. I would imagine they are at least using the PBKDF to generate enough output by increasing the iterations by one, and taking 256 of the 320 bits this outputs with SHA1, 128 to be used as key and 128 to be used as IV. If they are doing this, even though only the key is required to see if the password is correct, assuming they use the first 128 bits for the key, the lack of requirement of generating the IV on the attackers part would only remove 1 iteration per password. Considering they were using 1,000 iterations per password, having to do one less will not halve the number of required iterations. I think what they were doing was probably using one salt for the IV and one salt for the key, and doing 500 iterations of PBKDF2 for each of them, with the same password seed input. That is the only way I can imagine this attack as halving the number of iterations. If that is the case then it was a stupid implementation error on the part of 1Password, because even if they thought that CBC mode used the IV for every step of encryption AND decryption, they should have just used a single call to the PBKDF2 function and output 256 bits by sequentially iterating beyond the number of brute force protection iterations. Or they could have just used SHA256 to begin with, and doubled the number of iterations they were using. It is even more dumb because they don't even need to keep the IV secret, they could generate a random 128 bit IV and stored it in plaintext, then generated the encryption key from the password with the number of iterations they wanted. There is no real reason to generate the IV the way they were, and they were counting on iterations from PBKDF2 to generate the IV to slow down brute force attacks, which failed for them because CBC mode doesn't require the IV to confirm the key is correct. So they made a number of mistakes. The primary mistake they made was: A. Assuming CBC mode requires the IV for every step of decryption. This is a mistake I would forgive them for, simply because I thought the same thing until I heard about this and looked at the diagram on wikipedia. The IV influences every block of encryption, but only the first block of decryption. However, the attack could still have been prevented if they didn't: B. Think they needed to generate the IV from a password, or keep it secret at all. IV does not need to be secret, and there is no reason to generate it from a password. By generating it from a password, and counting on the side effect of PBKDF2 iterations in this step as part of their total number of iterations, they screwed themselves. C. Use SHA1 for some reason, even though they wanted 256 bits of total keying material. SHA256 is the logical choice here, and they could have split the output of PBKDF2 into two 128 bit sections , one for the IV and one for the key. Then they would have set the iterations in a single function call, and at worst the attacker would need to do one less iteration, if they use the first 128 bits as the key. If they did this and used the last 128 bits as the key, the attack would not be possible. D. Use two calls to the PBKDF. I am not 100% sure they did this, but it is the only thing that makes sense to me for how the attacker could halve the number of iterations. My educated guess is that they started with two salts, one for key and one for IV, then ran through 500 iterations of PBKDF2 with the salt for IV + password to get the IV, and 500 iterations of PBKDF2 with the salt for the key + password to get the key. Even using SHA1, if they simply ran 1002 iterations of PBKDF2 and took the last two iterations 320 bits and used 128 bits of it for IV and 128 bits of it for the key, they would not be vulnerable to this attack or only vulnerable to 1 lost iteration per password attempt, depending on the order they use the output bits in. So in summary, this flaw is the result of a combination of them not correctly understanding how the block cipher mode of operation they used works, and misusing PBKDF2. I think I would be hesitant to use their products.