Menu
Assumed knowledge
Hashing, Salting, PBKDF[1-2]
Problem
I am storing passwords in my database using a scaled hashing/salting algorithm like PBKDF2. I thought 'Hey, if i hash my passwords 20000 times, that should be secure enough against brute force attacks right?' and its true. until next year when better computers come out.
Possible solution
Leaving aside the issue of encryption key length, and salt length (which can be incorporated into this solution as well) I thought, what if every N days, i re-hash all the passwords in the database. So they are hashed 20,000 times, then a week later, i hash them a further 500 times, making them a total of 20,500 times. Store the number of times it has been hashed in the database somewhere. The idea is to increase the hash count as technology progresses.
Existing similar implementations
BCrypt introduces a work factor to increase time taken to hash a password:
PBKDF2 uses a number of iterations to do the same thing. This is used by Mac OS-X, windows and linux for file level encryption. Wi-Fi networks also use implementations of it.
Can anyone see a problem with this? Has this already been tried? Is there an algorithm out there that accepts a pre-hashed password and re-hashes it 'N' times?
Edit
The question is not if multiple hashing is secure (this has been tried and tested). The question is around re-hashing to increase security without having to make the users re-set their passwords
Solution: courtesy of discussion with JVestry
So re-hashing all the passwords every 'N' days is a waste of time since the hacker can just crack it by using an old copy of the database. However, if you combine the concept of increasing the hash count over time to a password renewal policy, the concept is sound.
Implementation
All passwords expire every 30 days. When they are renewed, their hash counter is increased. So a password reset yesterday will be harder to crack than one set 20 days ago. Hash counter can either be stored or derived from an algorithm using the last modified date.
Thanks!
TTD
343
Hash functions are designed to go only one way. If you have a password, you can easily turn it into a hash, but if you have the hash, the only way to get the original password back is by brute force, trying all possible passwords to find one that would generate the hash that you have.
No, multiple hashes are not less secure; they are an essential part of secure password use. Iterating the hash increases the time it takes for an attacker to try each password in their list of candidates. You can easily increase the time it takes to attack a password from hours to years.
Brute force is also used to crack the hash and guess a password from a given hash. In this, the hash is generated from random passwords and then this hash is matched with a target hash until the attacker finds the correct one.
There is a mathematical method to this madness, encrypting the plaintext password into its hashed form. Although these operations are easy to perform, they are difficult to reverse. Cracking a strong, encrypted password can take decades and ample supercomputing power to guess.
Can anyone see a problem with this?
Yes. Assuming that you would rehash weekly with the salt (which I believe is what you mean), there is still an issue. If someone manages to have access to a hashed password at week x, then any further hashing at week x + n does not provide any extra security.
The hacker only has to work on so much iteration at week x. Once a key is broken, he/she just has to hash it a little more like you do each week. This is dead easy and goes completely unnoticed.
If you rehash, do it with a new salt and from scratch with more iterations. Your shortcut does not bring extra safety.
168
This would make brute-force breaking harder, but also makes your login process slower.
You're better off using more salt.
34
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
