How To Secure Encrypted Password Even The Weakest One?

I am always looking for ways to secure my user's passwords. I am currently using some combination of hashing algorithm with random salt.

The main thing in this problem is when my user set a very very weak password. No matter how hard my mixed-up hashing algorithm, and how long my salt is, I think it can be cracked in less than 1 year.

I've been thinking for a new way. I've made a script that will re-encrypt the password every time the user sign-out by adding a random salt on the old hashed password, then encrypt it again. So, every time the user come back, the encrypted password is different. Get it?

But th开发者_JAVA百科e main problem on this idea is, I must store the new salt every time the user sign-out. Imagine my code will look like, if the user is sign-in and sign-out everyday?

Any idea?

Oh, I have an idea. How about regenerate new encrypted password every year?

Re-encryption doesn't help with your problem.

The only thing you can do is create a multi part hash, and hope the attacker doesn't get all of them. I usually use a two part salt:

One part is a random per user value stored in the database alongside the password.

The other part is a per application salt. You can store it in the application config or in a special password store the OS offers.

The advantage of that split is that it's not enough if the attacker just gains access to the database, but he needs to get access to wherever your application salt is stored. So for example a simple sql injection stealing your database isn't enough. If the attacker can execute code it probably won't help at all.

And you should use some method to slow down hashing. Typical hash functions are fast, so brute-force is fast too. But if you iterate the hash-function a million times it still doesn't slow down a valid login much, but slows down brute-force a lot.

You can achieve that using a Password Based Key Derivation Function such as PBKDF2.

You could use "key stretching": iterate the hash, say, a million times, after salting. Then store hash value, salt, and iteration count. Then an attacker could check a million times fewer passwords per second than when you hash once. But a very short password will still fall: note that you yourself, to verify the legitimate password, need to do the same operation. Suppose you accept a 1 second time for yourself to check, then the attacker can also check passwords at 1 second per password, on a similar machine (and more if he used more or faster machines!). And 1 second per password can still be enough to check for weak and short password, standard dictionaries etc. There really is no defending against it, only making it harder.

There are two problems with your main assumptions. The first one is about the problem of storing the salt. You already do for the salted password solution. With your new approach, salt would change over time, and that's it. So you could have used this method and the only extra cost would be the re-calculation of the hash value at every login (when you actually have the password string itself).

The second problem is the more important one: a re-hashing will not change anything. As soon as your attacker gets hold of one salted hash value, it will be enough to mount a dictionary attack. The fact that you change your salts and the hash in your database will not make it any more difficult. So there is no need to recalculate a hash after the first one is created.