In summary: the idea behind password cracking is just to replicate the password validation procedure of a web server locally with lots and lots of attempts and check whether the output of that verification matches any known leaked hash.
However this kind of attack is only possible if the procedure by which the webserver validates a password is known by the attacker! The way I understand it, there would no way for an attacker to crack passwords if each webserver "handcrafted" their own password hashing procedure (unless the attacker got their hand on that procedure of course)
Let me clarify: What I mean by handcrafting a hashing procedure is not "come up with a custom hash function" but rather a custom procedure to modify the clear data before hashing it with a known hash function.
For instance :
- Take the password in clear.
- append the first n letter of the username
- generate a key with, (let's say you generate that key from the account creation date) and then encrypt it
... how many steps you can come up with?
- hash the result and store it in the database
Heck, you could even generate a different procedure for each password based on the account information...
I'm not pretending this particular procedure is worthwhile, I've just typed that from the top of my head but you get the jist of it.
Of course that's not bulletproof as now you have to keep your algorithm secret, but that would at least circumvent database leaks from sql injection for instance.
Would this be advisable? If not, why? Is that common practice?
(I have no formal training in cryptography whatsoever so I do realise that I could be missing something really obvious that renders this whole idea completely useless)
PS : now that I realise, this "procedure" idea could be replaced by a digital signature.
As a webserver, you take the password, hash it, then sign it with a private key. Then only someone who knows the private key could replicate the password verification.