3 ms·
That's what I did when I migrated our application to bcrypt some time ago. I had some questions about whether using an md5sum as the bcrypt input, with much le
by chrismsnz 14y ago
That's what I did when I migrated our application to bcrypt some time ago.
I had some questions about whether using an md5sum as the bcrypt input, with much less keyspace (only hex characters) had any impact on security but nobody could/would answer.
I'm guessing that knowing that the plaintext for the bcrypt hash is always going to be 16 characters of 0-9,a-f might have some impact on crypto analysis but considering the passwords most people use I'm guessing it's only going to be a net win in terms of entropy.
- bigiain 14y agoYeah sure, bcrypt(salt, md5/sha1(password)) is in general less "secure" than bcrypt(salt,password)#, it's still more secure than md5/sha1(password). # Note though, that you need at least 20 printable ascii chars to get the 128 bits of entropy possible in an MD5 hash, so for _most_ passwords, you could optimize your cracker by only bruteforcing bcrypt(salt, md5/sha1(password)) using shorter strings as password guesses rather then needing to bruteforce the whole 128 bit MD5 space. With bcrypt and salt though, that turns into an "only practical for state-level attacker" I think.
- __alexs 14y agoOnly for users with >128/160-bits of entropy in their password, which probably means your password is well over 20 chars long.