04-29-2017, 08:14 PM
We can probably be a lot smarter than the author of the PHP script.
We will need to look at the vbox code to verify a few things, but the second call to pbkdf2 is wholly unnecessary if $decrypted_password == $user_password. Can simply hash, decrypt, compare, done. However, if $decrypted_password is e.g. some randomly generated value, we still probably have an opportunity for an early reject here. Like if we know that $decrypted_password will always be e.g. a-zA-Z0-9 then we can reject the candidate if the trial decrypt results in values outside that range, and only do the second pbkdf2 call when we have a likely password.
What's also interesting is the "final hash." Again need to look at the source, but typically pbkdf2 is used to derive an encryption key, and the final hash is the key. If they're storing the final hash value, then are they actually storing the encryption key?? Definitely something to look into!
We will need to look at the vbox code to verify a few things, but the second call to pbkdf2 is wholly unnecessary if $decrypted_password == $user_password. Can simply hash, decrypt, compare, done. However, if $decrypted_password is e.g. some randomly generated value, we still probably have an opportunity for an early reject here. Like if we know that $decrypted_password will always be e.g. a-zA-Z0-9 then we can reject the candidate if the trial decrypt results in values outside that range, and only do the second pbkdf2 call when we have a likely password.
What's also interesting is the "final hash." Again need to look at the source, but typically pbkdf2 is used to derive an encryption key, and the final hash is the key. If they're storing the final hash value, then are they actually storing the encryption key?? Definitely something to look into!