0

Let's say I my password is a simple password, 123456

Then if the database was exposed, if the password was:

-- stored in plain text -> cracked
-- stored it hashed with no salt -> prone to rainbow tables -> cracked
-- stored it hashed with salt -> rainbow tables are less effective since a specific rainbow table for each salt will be needed, but at the end at least one important password can be cracked
-- stored it hashed with bcrypt -> slower time to generate that rainbow table, but at the end a powerful machine/s targeting one important password can crack it.

Can we avoid this if we chained two hashing algorithms to one hashing process ? For example hashing a password with SHA-256 hashing, then hashing the output with bcrypt ? Bcrypt(Sha(Pwd))

This way the output hash doesn't appear in any rainbow table, even it was a rainbow table made specifically for my salt I used with bcrypt and its work factor, the output is still another hash value that's not included in the rainbow table. And also brute forcing best chance will be finding the hashed value of the Sha(Pwd) (which as I think is also computationally infeasible?)

Improve this question
3
  • Your explanation helps clarify a little, but the initial question "ultimate solution" makes it seem like you are asking if multiple rounds of hashing is all that would be required. Would you consider rephrasing it? Multiple rounds of hashing is just one part of secure password management, but it is not the only part.
    – iraleigh
    Apr 25, 2020 at 4:49
  • I modified it to hashing algorithms, because I didn't mean chaining multiple hash rounds like what bcrypt does, I meant chaining multiple algorithms
    – Youssef Mohamed
    Apr 25, 2020 at 4:56
  • 1
    Let me give you a tip for when you think you have some revolutionary idea: Assume that there are tons of people that have way more experience than you. Assume they already had that idea, and dismissed for some reason. Use that as the basis of your question. Because "Why does X not work?" is a better place to start off than "Is X the solution to all our problems?"
    – user163495
    May 25, 2020 at 10:29

2 Answers 2

Reset to default
2

... but at the end a powerful machine/s targeting one important password can crack it

If you mean with "at the end" in a couple of 1000 years then you might be right. The main point of salting and slowness is that it is practically infeasible to build rainbow tables (would be too big due to salting) or to brute-force good passwords (would be too slow due to slow hash). There is no need to add yet another layer on top of this.

And essentially what you propose is to just replace a slow hash with an even slower hash. This can already be achieved by just using more rounds in the existing password hashing algorithms, i.e. they have these feature already build in.

Improve this answer
2
  • From what I read that with a set of multiple computers with decent GPUs a rainbow table formation, by running bcrypt with X rounds and specific salt on the list of (rainbow table keys) , can be generated hence the needed password in a lot less time than 1000 years
    – Youssef Mohamed
    Apr 25, 2020 at 5:28
  • @YoussefMohamed: "From what I read ..." - please provide the actual source for this. Either the source is wrong or you've misinterpreted it. Note that you can actually read here the opposite, so "what I read" does not really count, facts count instead.
    – Steffen Ullrich
    Apr 25, 2020 at 5:40
1

There is absolutely no advantage to hashing the password with a fast hash before passing it to the password hashing function. The fast hash would become part of the password hashing algorithm, for example you'd be using the password hashing algorithm SHA-256+bcrypt instead of bcrypt. The attacker would just have to tweak their password breaking program to run your algorithm instead of the standard one.

You misunderstand how rainbow tables work. Rainbow tables are a way to perform a long calculation upfront, and then break many hashes that have the same salt (or no salt) quicker than brute force. This upfront calculation is longer than the time it takes to break one password directly. So if the hashes are salted, rainbow tables are slower than a direct attack. See Why are salted hashes more secure for password storage? and What are rainbow tables and how are they used?

Regardless of this misconception on rainbow tables, pre-hashing the password would have no benefit. Let's say that you used SHA-256+bcrypt with an empty salt for all your passwords, so that rainbow tables would be meaningful. Then the attacker would just build a rainbow table for SHA-256+bcrypt[salt=empty] instead of building a rainbow table for bcrypt[salt=empty]. The SHA-256 step would be extra attack surface for no security benefit.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .