Avoiding password cracking by using custom hashing procedure?

  • 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 :

    1. Take the password in clear.
    2. append the first n letter of the username
    3. 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?

    1. 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.

  • The problem is that you would need to justify the extra design, and subsequent processing costs, against the benefits. Then compare that to simply using established, strong, hashing processes.

    And, as you say, all that extra effort and cost remain while the benefit evaporates once someone knows the procedure you use.

    Instead, what people do is design strong hashing processes that do not need to be a secret and do not need "custom" hashing beforehand to remain strong. This approach follows "Kerckhoffs's principle".

    Yes, there are cases where "obscuring" your process can have a place, but those cases tend to be niche and obscuring solves a very particular problem. It's not a great general design principle.

    A Pepper is a version of obscuring. The problem is that once someone knows the pepper, its benefit goes away. Peppers have very specific use cases.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2