Usual password verification schemes stores a salted password hash and the salt.

Question

Usual password verification schemes stores a salted password hash and the salt. If the hash is good and computational costly, it is considered secure.

However an alternate version (used in Microsoft Office and probably other places) generates N random bytes (eg 16 bytes) and a M byte hash of the N bytes (say an additional 16 bytes), concatenates them and encrypts the concatenated N+M bytes using some encryption algorithm and a key derived from the password.

To verify the password, the N+M bytes are decrypted, the first N bytes are hashed and compared to decrypted M bytes. If they match, the password is considered verified.

To my untrained eyes, the introduction of random data (of sufficient length) makes this system secure against any table look up scheme even if the hash is weak. It only seems to depend on the strength of the encryption and the key length.

Am I wrong? Where?

Explanation / Answer

This scheme is ok, but it's basically just a variant of a salted hash. These are generally considered old practice. Furthermore, this scheme is more complicated (more surface area for potential bugs) and relies upon multiple cryptographic algorithms being unbroken.

Modern good practice is that passwords should be stored using a slow key derivation algorithm such as PBKDF2 or bcrypt. These ensure that lookup tables are infeasible, and that cracking all but the weakest and most common passwords is extremely expensive.

Related Questions

Navigate

• Browse (All)
• Browse U
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.