asked on Using random iterations in password hashing. Good or Bad?
Hi there,
I am currently using individual salts per password in my hashing solution.
My understanding is that using salts helps to prevent people from using lookup and rainbow tables to crack the passwords.
Due to legacy issues I am using the PBKDF2 algorithm inside the .NET Rfc2898DeriveBytes cryptology class which I believe uses HMAC based on SHA1. With this in mind I am looking at alterative ways to strengthen my password hashes.
I read a comment in an article that if you randomise the number of iterations for each password (iterations are stored with the salt for use when verifying password) that this also helps with beating rainbow table attacks.
As I can't find anywhere else that seems to mention this method I was wondering if anyone knew whether the randomising of iterations was actually a good idea or simply an unnecessary step? Could it in fact be a bad idea?
My thoughts are that even a matching hash at a different iteration count wouldn't result in the hacker knowing the actual password.
I am currently using individual salts per password in my hashing solution.
My understanding is that using salts helps to prevent people from using lookup and rainbow tables to crack the passwords.
Due to legacy issues I am using the PBKDF2 algorithm inside the .NET Rfc2898DeriveBytes cryptology class which I believe uses HMAC based on SHA1. With this in mind I am looking at alterative ways to strengthen my password hashes.
I read a comment in an article that if you randomise the number of iterations for each password (iterations are stored with the salt for use when verifying password) that this also helps with beating rainbow table attacks.
As I can't find anywhere else that seems to mention this method I was wondering if anyone knew whether the randomising of iterations was actually a good idea or simply an unnecessary step? Could it in fact be a bad idea?
My thoughts are that even a matching hash at a different iteration count wouldn't result in the hacker knowing the actual password.
EncryptionSecurityWeb Servers
Last Comment
gheist
ASKER
If that was the case then wouldn't that be true for any algorithm that has iterations?
Correct me if I'm wrong but a match at an intermediary iteration wouldn't result in them finding the actual password though. Wouldn't they need to find a match at the final iteration in order to determine the password?
Correct me if I'm wrong but a match at an intermediary iteration wouldn't result in them finding the actual password though. Wouldn't they need to find a match at the final iteration in order to determine the password?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
If you change number of iterations you might weaken encryption (like introduce 'meet in the middle' problem)
Using lightly tweaked algorithm will require custom programming of password cracker, but it will not make cracking significantly faster or slower.
Using lightly tweaked algorithm will require custom programming of password cracker, but it will not make cracking significantly faster or slower.
* A cracker can check for a match in all intermediary hash iterations