Is it stupid to not save the last two characters of a password hash

Question

As any good password storing developer I have user unique salts that I use to generate password hashes. ie I store a uniquesalt and SHA1(salt + password + "applicationuniquestring") in the database for each user.

If someone were to get my database they could theoretically create a rainbow table for every user and have at it until they crack it.

But what if I didn't store the last two characters of the generated hash.

Con: This would make the chance of a wrongly entered password being accepted higher (but probably not so high that I really care).

Pro: It would also make it pretty annoying to try to get the password back as what ever you do there are ((26 + 10) * (26 + 10)) = 1296 possible endings to the hash you don't know.

And if you were to try to guess and brute force all those combinations back and try the different combinations.. well even a poorly coded service should flag you after about 100 failed login attempts...

Now this might be stupid for many reasons but I cant think of them now.. Now please chainsaw this idea before I implement it.

Answer 1

Rule number one of cryptography: don't roll your own crypto. You're taking a standard cryptography algorithm and you're messing with it. If the algorithm or combination of algorithms you're using hasn't been evaluated by security researchers for the past few years, you have no idea whether you've created a vulnerability or not. Stop right now. Using standard, widely tested algorithms is the safest thing to do.

Additionally, your question makes two very bad mistakes in terms of password hashing security:

1. You're using a single SHA-1 hash. SHA-1 is too fast; it's broken for password hashing. See here or here. (Note that my use of the word "single" doesn't imply that you should just apply SHA-1 iteratively. There's more to it than that.)

2. You've fundamentally misunderstood what a rainbow table is for. A rainbow table is a set of pre-computed data that can be used to more efficiently search for matching inputs for hashes. The problem is this statement:

   If someone were to get my database they could theoretically create a rainbow table for every user and have at it until they crack it.

   If an attacker has to generate a rainbow table per user, then the rainbow table is no better than just brute forcing each user. You've already rendered the rainbow table worthless by using a unique salt per user.

These show you don't have a great understanding of password security or cryptography. The two mistakes you stumbled across only require passing knowledge of the subjects to avoid. So you definitely shouldn't be trying to develop your own security schemes until you've acquired much more knowledge. (I know that's harsh, but you did ask us to stop you.)

We can also invoke Kerckhoffs's principle . Kerchoff's principle states that the system should remain secure even if the attacker knows all the implementation details. The reason this is so critically important is because attackers are actually very, very clever at figuring out the details of your system, even given surprisingly few details. So let's evaluate your change in that light. Does this change offer any benefit if the attacker knows about it? No, it does not. An attacker can easily adjust their attack pattern to deal with this once they figure it out.

In fact, there's some possibility it could be a detriment. By using a shorter hash, you guarantee that there will be more collisions with other passwords, which might make it easier for an attacker to gain unauthorized access to your system by finding a password that has the same hash. By how much? I don't know. Maybe not much; I'm not going to spend a lot of time working it out since there are plenty of other arguments against this being helpful.

Bottom line: don't roll your own crypto. The current standard algorithms probably aren't perfect, but they're vastly more battle hardened than anything you or I will come up with.

Answer 2

As you have pointed out in the question, all you are doing by dropping the last part of the hash is creating more password strings that are considered valid passwords for that user.

In effect that means that as there are multiple valid passwords, it's easier to find just one password that works.

The attacker has no need to find the same password that the user uses.

In short, it is a bad idea.

Answer 3

Yes, it is stupid.

You are counting on a little bit of obscurity (two dropped characters) for a slightly weaker hash. Given hash sizes tend to be well known, I wouldn't expect this to be a significant barrier.

Answer 4

There is one case where your idea would help: If some hacker organisation has created huge rainbow tables, and provides a web interface where you enter a 128 bit hash, and they tell you the password (if available). Since an attacker would only have 112 bits, they would have to consult that web interface up to 65,536 times, 32,768 times on average, to get your password.

But that's unrealistic. If the hacker can just slightly change the code that looks up a hash in these rainbow tables, then looking up a code with the last 16 bits missing is just as easy as looking up the full code.

But the hacker shouldn't be able to use rainbow tables, and indeed they are not. That's because you are using a different salt for every password, plus another salt for your application. So every single hash must be cracked individually.

And cracking a password hash means the hacker has to try every single password until they find the right one. Since you store only 112 bits, trying systematically 4 million billion billion billion passwords will find a password that can be used to log into one account. This is most likely not the user's actual password, so it cannot be used to log into other sites where the same password was used. However, you can't crack a password hash that way. Instead, you figure out for example the 10 billion most likely passwords and try them. Now if the hacker finds a password that hashes to the right 112 bits, the chance is one in 250,000 billion billions that it isn't actually the right password, that's negligible.

So your scheme does nothing to improve your security and the user's security. Unless you used a scheme that is totally insecure in the first place, which you are not doing.

Answer 5

I do admit that this idea sounded interesting at first..

However, the real cost of recovering a salted password is that the attacker cannot use a traditional (already hashed) rainbow table and must use the salt to generate the hash for a list of common passwords.

The attacker may notice that 2 characters were missing and just drop 2 characters from their generated hash.. their process would not change other than that detail.