3 ms·
One of the many mistakes by Adobe revealed in the recent hack was their use of ECB to encrypt passwords. The basic problem with ECB is the same input always re
by spikels 13y ago
One of the many mistakes by Adobe revealed in the recent hack was their use of ECB to encrypt passwords.
The basic problem with ECB is the same input always results in the same output. And this applies not only to the entire input but specific subsections of the input, known as blocks. This leaks substantial information.
In the Adobe leak accounts with identical passwords were easily identified as they had the same encrypted password. Frequency analysis can then be applied to find common passwords ("123456" is often the most common...). Even worse Adoble also leaked the password hints so you often had thousands of different hints to help you guess a single password.
Of course you should not even be encrypting password in the first place (use a cryptographic hash with an individual cryptographically random salt for each password NO! SCRATCH THAT. JUST USE BCRYPT!) but that's another issue...
http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/ http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-pass...
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#...
Edit: Corrected based on tptacek's comment below.
- tptacek 13y agoSalted hashes are a very poor way of storing password authenticators. http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ There are much more significant problems with using ECB than simple frequency analysis suggests.
- spikels 13y agoI kinda expected you to correct me. You can't help yourself can you. :) And that is a good thing. Thanks! Sorry I was not trying to give the entire recipe for password handling. I was assuming a KDF with lots of iterations. But perhaps you could clear up one thing: Assuming proper implementation (I know a big assumption) how is bcrypt better than PBKDF2 with lots of iterations using a good hash and salt? At some bcrypt cost and PBKDF2 iteration count wouldn't they be equally secure?
- tptacek 13y agoPBKDF2 is straightforward to accelerate in commercial off the shelf hardware, and bcrypt isn't. But both are fine. Neither are "salted hashes".
- spikels 13y agoI guess I had my terminology wrong you would know better. I always thought of PBKDF2 as simply "iterated hashing of a salted password".
- B-Con 13y agoYour mental model isn't necessarily wrong. The phrase "salted hash" generally refers to something more plain than PBKDF2. PBKDF2 is technically a "Key Derivation Function", but it can also be used as a "Password Hash Function". Password Hashes generally use a hash function and a salt, yes, but they also incorporate other important factors as well, commonly a work factor and some "hard" computational problem, so it's unfair to call them merely a salted hash. PBKDF2, along with password hashes in general, do indeed do everything a "salted hash" would do, but importantly, they also do more.