3

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.

  • 2
    If I understand correctly, the only "advantage" of your proposal is that each hash would potentially accept multiple passwords instead of just one. Why would you want that? – Tanner Swett Aug 26 '16 at 21:11
  • 4
    Please don't cross post. If you want to have it here you need to delete it there. – candied_orange Aug 26 '16 at 21:21
  • 2
    If you cut the last two characters off your stored hash, you're making it quicker for someone to discover a collision (which is all that rainbow tables do). Take the idea to the extreme - reduce your stored value to only two characters. How much faster to generate a collision now? – HorusKol Aug 26 '16 at 23:05
  • 1
    Instead of removing them, why not replace the last two with random chars? Same effect but hidden. – Bohemian Aug 27 '16 at 0:30
  • 4
    @Bohemian Because security through obscurity is a bad idea. A good system is secure even if the attacker knows all of its inner workings. – jpmc26 Aug 27 '16 at 0:39
18

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.

  • not significantly increase the time 256x is significant in my mind. And it could be more if he drops more. – usr Aug 27 '16 at 19:29
  • 2
    @usr I don't know where you get the idea it's 256 times slower, but even if it is, I'm confident that's lost against the increase in collisions. The bottom line is simple: the OP does not understand cryptography and has no business messing around with this stuff in a production application. They should use something standard, probably bcrypt. – jpmc26 Aug 27 '16 at 19:40
  • 2
    ' Stop right now'. Sounds about right. – David Aug 28 '16 at 0:16
  • I thought you suggested this by saying that the time increases at all but apparently not. I think I misread the text a bit yesterday. – usr Aug 28 '16 at 9:02
4

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.

  • Hmm. I always considered hashing and salts main purpose to be that the attacker could not lift the password along with email and username from your database and try it on different sites. To this purpose this should be better. You are however correct in that it would make my login slightly less secure though. – JensB Aug 26 '16 at 22:56
  • And that's why secure sites use password rotation, complexity rules and also have 2 factor security. It means that if someone cracks your password it's still useless. – Michael Shaw Aug 26 '16 at 23:16
  • This is the true answer. Rainbow tables do not apply due to the salt. So all that this idea does it create more valid hashes. – usr Aug 27 '16 at 19:35
2

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.

  • Do you mean 'yes it is stupid' because it is not a barrier for hackers or 'no it isn't stupid' as it is barrier for hackers? – Bent Aug 27 '16 at 13:02
  • Yes it is stupid. I will edit for clarity, though I believe that @jpmc26's response is better. – Jim Rush Aug 27 '16 at 15:37
0

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.

-1

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.

  • But with this method, even after they have done all the work, they would still have 1296 different solution variations. And no way to limit that down further. So even if they notice the two missing pieces what can they do about it that actually helps them? – JensB Aug 26 '16 at 22:01
  • 2
    @JensB Most users don't pick random passwords (and the ones that do won't get their passwords brute-forced). The attacker's going to try the most common passwords against all accounts in parallel. It's incredibly likely that if "letmein" matches one of your user's hashes, "letmein" is that user's password and not one of the 1295 other possible passwords. And even if it's not, your system will still let the attacker log in using that password. – Doval Aug 26 '16 at 22:54
  • Also. The purpose of this would not be to make my site safer.. but to make the users passwords safer. See my comment to Michael Shaw above. But you are right in that users probably have some words and not !21321Ms as a password which would make this all less worth while.. – JensB Aug 26 '16 at 22:59
  • 2
    But all 1296 possible results will work because when salt and hash the attempted password you can only compare the hash without the last two characters because that is all that you have stored – HorusKol Aug 26 '16 at 23:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.