Take the 2-minute tour ×

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 the 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?

share|improve this question
Just use a very long salt, or start enforcing standards on peoples' passwords. –  Marcin Feb 27 '11 at 13:45
add comment

3 Answers

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.

share|improve this answer
I get it. So the idea is to slow down the brute force as low as possible? I'll try this one. –  dimassony Feb 27 '11 at 13:58
That's the idea of the second part. But of course you slow down legit logins by the same factor. So it's a trade-off between the computational cost of a login and slowing down the attacker. Depending on the user numbers a good compromise is probably around 10ms for server application and 1 second for disk-encryption. –  CodesInChaos Feb 27 '11 at 14:10
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
Yes. But it will be harder (I guess) cause the string is longer. EX –  dimassony Feb 27 '11 at 13:43
I don't get why that would be the case. The password is the same, and the salt changes from S1 to S2. The original S1, H1 values are still valid, but you store S2, H2 in DB now. What string is getting longer? –  vhallac Feb 27 '11 at 13:46
I see. So, do you have any idea? –  dimassony Feb 27 '11 at 13:53
@dimassony There is not much you can do against weak passwords. No matter what your underlying mechanisms are, they are open to a dictionary attack. CodeInChaos's answer has a few good approaches to increase the attack time. –  vhallac Feb 27 '11 at 19:14
add comment

Your Answer


