Well they used the standards (AES-128-CBC, PBKDF2, SHA1) , and didn't strictly speaking roll their own encryption (although they did roll their own cryptosystem), but they used the standards incorrectly. It would be like using seeded SHA256 for a PRNG, but only hashing out from the seed, without concatenating the seed to each output iteration before rehashing to get the next output iteration. Although that would be rolling your own PRNG, so it is not a perfect analogy. At least they knew to use a PBKDF, an even worse situation would happen if they had simply used SHA1 for the key without combining it with a PBKDF. In either case they would have used the standards, but it would be a misuse in either case. In their case the number of iterations was halved, from 1,000 to 500, had they used SHA1 with no PBKDF there would have only been one iteration. But even though this shows that they didn't know how the mode of operation they used worked, or how to correctly use PBKDF2, the effect on end users should be fairly minimal. PBKDF stands for password based key derivation function. It is used to derive a key, for use in encryption operations, from a password. Generally it works like this: You provide a salt, a hash function and a number of iterations. Let's say your salt is 'abc' , your hash function is SHA1, your number of iterations are set at 2 (way too low!), and your password is 'def'. So the first iteration will produce the SHA1 hash of 'abcdef' bdc37c074ec4ee6050d68bc133c6b912f36474df the next iteration will produce the SHA1 hash of the first iteration e3cd537dc0c5da5cc5360dab38faf6fcee29a2f8 and this is the key derived from your password run through that KDF. This is beneficial when you have a lot of iterations, because it makes it so the attacker must use more computational power, which translates into more time, in order to brute force your password. It also protects from rainbow tables because of the salt. Assuming the attacker guesses your password correctly the first time, if there are two iterations of the KDF, it means they must do two hash operations to derive your key. Without a KDF, they would only need to perform one hash operation to derive your key. Since they have to do two operations with the KDF, it doubles the amount of time required for them to crack your password. If you use 1,000 iterations, it multiplies the amount of time required by 1,000. This is really nice for slowing down brute force attacks, but it isn't a replacement for a good password. It may make a very bad password into a bad password, but it will not make a okay password into a strong password. An 8 bit password has a key space of 256, 2 ^ 8. That means without using a KDF, the attacker has to do at most 256 hash operations to crack your password. With a KDF that uses 2 iterations, they need to do at most 512 hash operations to crack your password. log2(2 ^ password_strength * KDF_iterations) = password_strength with KDF Keep in mind that it gets unrealistically slow for a user to generate their keys as you go up orders of magnitude in the number of iterations. Most programs use somewhere in the area of 1,000 iterations. log(2^81000)    = 17.96 bits with 1000 iterations log(2^810000)   = 21.28 bits with 10,000 iterations log(2^8100000)  = 24.60 bits with 100,000 iterations log(2^81000000) = 27.93 bits with one million iterations log(2^1281000)   = 137.00 bits with 1000 iterations log(2^12810000)  = 141.28 bits with 10,000 iterations log(2^128100000) = 144.60 bits with 100,000 iterations log(2^1281000000) = 147.93 bits with one million iterations As you can see, adding a single random 8 bit character to a password is more effective at increasing password strength than going up two orders of magnitude in the number of PBKDF iterations you use. Adding 1000 iterations to an 8 bit password more than doubles the bit strength of the password, but adding 1000 iterations to a 128 bit password doesn't anywhere near double the bit strength. So even though it is best to use a PBKDF to give some extra bit strength to the password, even not using one at all isn't the end of the world if the user has a good password. And adding orders of magnitude more iterations greatly increases the amount of time it takes for the user to generate their key, and is less effective than the user adding a single additional character to their password. I am pretty sure that 1Password used PBKDF2 twice, once with a salt for the IV and once with a salt for the encryption key. So lets say once they call it with '1PasswordIV' + 'Password' , for 500 iterations with sha1 and once with '1PasswordKey' + 'password' , for 500 iterations with sha1. They were banking on CBC mode requiring the IV for all steps of decryption to see if the password was correct, so they assumed that they were using PBKDF2 with 1,000 iterations. The attacker saw that they didn't understand CBC correctly, and that they used PBKDF2 weirdly, and so they entirely ignored the '1PasswordIV' + 'Password' for 500 iterations step, cutting the amount of effective iterations in halve. The problem would not have arisen if the 1Password people correctly understood CBC mode decryption, or if they did something like '1Passwordsinglesalt' + 'password', for 1002 iterations with sha1 and took 256 bits from the last two iterations as their output, using the first 128 for the IV and the last 128 for the key. Or if they didn't generate the IV from the password at all, and used 1000 iterations for the key. Or if they used sha256 and a single call the PBKDF2, then split the final iteration as I described previously.