Quote from: FelipeAquinoBr on May 07, 2018, 05:57:46 PM

--snip--

Hello Friend! The text must have gotten a bit confusing, because it is actually the encrypted password entered in the database and then it will only be decrypted if it has the 5 parts together. Even if a hacker invades the database will not be a risk, because he needs to join the 5 parts in 1 minute and still access the database.

I've been writing web applications for my employer for quite a while... I'm not a good scripter/programmer and defenatly a bad designer, but i do know a thing or two about security... Things i've picked up over the years

Let's review 2 situations from a malicious person's view:
Situation A: You store your passwords, chopped in 5 pieces and encrypted into a database

Would it be imaginable you wrote a single bug somewhere in either your code or your webpages? An attack vector you didn't think about? A misconfiguration of your apache/nginx/lighthttpd? A misconfiguration in your database installation? A weak OS/db password? An unpatched binary? If so, would it be unimaginable that the attacker could find a backdoor or a sql injection point that allowed him to dump your database, thus getting his hands on all 5 encrypted pieces of all passwords stored in your database?
If the attacker got his hands on hundreds of chopped up passwords, would it be imaginable that he found the logic in how to decrypt your passwords? I mean, unless you encrypt the pieces using an offline machine, the passphrase or key *would* technically be hardcoded or stored in a database somewhere on an online machine, right? If the password or the logic wasn't stored online, how would you ever encrypt/decrypt the pieces yourself? The same attack vector as the one in step one *could* *potentially* be used to rip your sourcecode to look for the hardcoded password/password logic
IF an attacker managed to get past the first 2 hurdles, would it be imaginable he could then execute the first step and apply what he learned in the second step and decrypt NEW passwords in a matter of seconds?
Sure, this is a longshot, but if your service ever becomes *the next big thing*, you should be prepared for really smart evil people investing a lot of time into breaking your security model... So why not build it foolproof from the start?

Situation B: You store your passwords, not chopped but stored as a SALTED hash in your database (for example, bcrypt with a high cost)

Would it be imaginable you wrote a single bug somewhere in either your code or your webpages? An attack vector you didn't think about? A misconfiguration of your apache/nginx/lighthttpd? A misconfiguration in your database installation? A weak OS/db password? An unpatched binary? If so, would it be unimaginable that the attacker could find a backdoor or a sql injection point that allowed him to dump your database, thus getting his hands on the salted hash?
Now here is where things get different: even if he dumps all passwords, he needs to brute force each and every one of those passwords starting from 0. Since you have long passwords, and they got salted during the encryption process, there is simply no way he'll ever be able to brute force a single password within any reasonable timeframe

In situation B it doesn't even matter if your complete sourcecode, password file and database dump ever get leaked... The attacker won't be able to use that information to decrypt the password hashes.
As long as there are no rainbow tables for bcrypt passwords with a length of 23-25 characters are generated, your users will always be safe (hint: i don't think such rainbow tables will exist in our lifetime... It would require bcrypt asics and a corporate SAN to generate and store this data)

And from a programming point of view: what's the difference between comparing two plaintext strings and two hashes? The only extra cost is that you have to hash the user's input twice... Costing you a couple processor cycles and maybe a couple miliseconds... Seems like a fair price to protect your users, doesn't it?