Why can't SHA512 be used in a password algorithm if we iterate it enough to create it slow? Example is to SHA512 the password 100k times.
Why can't SHA512 be used in a password algorithm if we iterate it enough to create it slow? Example is to SHA512 the password 100k times.
There isn't any reason why this cannot work. This is what PBKDF2 essentially is.
Why is PBKDF2 or bcrypt recommended instead of doing the above? Or why is it not?
Why is PBKDF2 or bcrypt recommended instead of doing the above? Or why is it not?
PBKDF2 is essentially taking a SHA hash and iterating it multiple times.
bcrypt on the other hand, uses the blowfish algorithm and requires more memory access to perform, which isn't very efficient on a GPU. This makes it harder for an attacker with a GPU to speed up the cracking process. This is the same as scrypt, by extension.
If a PBKDF2 function relies on SHA1 underneath, is it inherently insecure if SHA1 can be proven broken?
If a PBKDF2 function relies on SHA1 underneath, is it inherently insecure if SHA1 can be proven broken?
From my understanding, yes.
The reason why people suggest using key derivative functions for hashing is that the time needed to crack the password hash can be increased by simply raising the iteration count. This makes it easier to keep the hashes secure as hardware gets increasingly powerful without changing the hashing algorithm.
Implementing bcrypt isn't very complex as there are many simple to use libraries that does the job for you. For example: phpass for perl, php and python.
I'm not exactly a crypto expert, so take my answer with a grain of salt. However, this seems to be the general consensus from experts from what I have read.
With regards to the first link, I believe his response was just to the question, there is no official NIST requirement for using PBKDF2 for hashing passwords. It is still better than a simple SHA hash though.
