OpenSSL allows PBKDF2 to output as many bytes as you tell it to with a single function call, but I am not sure exactly how they achieve that. I should test it and see if it is just hashing x times and discarding the remainder. Considering the OpenSSL implementation of PBKDF2 is likely by far the most commonly used, it seems like this could very well be a flaw in OpenSSL that extended to 1Password. After reading a bit more about the technical details of this attack, it becomes apparent that it is hardly really a flaw in PBKDF2 though. It is a flaw in the way they used it. If they used it with a cipher in CTR mode this attack would not be possible. It is really a pretty subtle attack, I would have definitely overlooked it myself because I always thought in CBC mode the IV influences every single block, but looking at the Wikipedia diagram of it I can see now that this is only the case for encryption, not for decryption where only the first block is affected by the IV. I would expect a professional cryptographer to never make such a mistake though, or even someone implementing something using CBC mode, as I would hope they look at the diagrams on wikipedia first at least. In CTR mode the IV influences every single output byte, for encryption and decryption. So their mistake was in using two calls to PBKDF2, with one for the IV, when the IV is not required to determine if the key is correct in CBC mode decryption. Also it seems like he could have used the first set of output bytes of the KDF as the IV and the second set as the key. Then attackers would need to generate the IV associated with a password before they could generate the key associated with it. Or he could have even not generated the IV from the password, and doubled the number of KDF iterations. the IV doesn't need to be secret, and probably shouldn't be based on the same password that is used to derive the key anyway.