0

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.

5
  • 1
    Or you could just use a pepper.
    – nobody
    Apr 21 at 14:09
  • @nobody Well... Yes. I didn't know that existed. I only knew about salt... After looking at it on wikipedia, it's essentialy what I proposed here. Is that common practice ?
    – Lumburel
    Apr 21 at 14:12
  • Not too common in my humble experience, but not too rare either. And as schroeder says, the benefits of a pepper are limited.
    – nobody
    Apr 21 at 14:29
  • 2
    Don't. The problem of password storage has already been solved.
    – MechMK1
    Apr 21 at 14:52
  • FWIW, answering the deeper defense question: one "herd health" method I've been frustrated by (as an attacker): randomly varying the work factor (within a given strong range). This is good because many cracking suites can only attack a list with identical work factors. For example, if you had 100K users and your PBKDF2 implementation selects a random work factor from 25,000 through 30,000 (or whatever - YMMV) as each hash is created, then only a few will share the same work factor - so attacks can only target a few hashes at a time. If it makes me mad, you probably want to do it. :D Apr 22 at 17:04
4

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.

5
  • Thank you. I did not formally know about "Kerckhoffs's principle". I understand the fact that "security by obscurity" is generally frowned upon. However I feel like that adding obscurity on top of an already "proven" design could not hurt. In theory at least, as you said such extra design would add cost and complexity. The questions that then comes to my mind is this : In practice and statistically speaking, do database leak often involve web app (as in source code) disclosure ?
    – Lumburel
    Apr 21 at 15:01
  • If someone can get the database, then they are equally likely to get the source code. They will want to know what hashing method and settings were used, after all.
    – schroeder
    Apr 21 at 15:39
  • Well, pretty likely - but I wouldn't say equally likely - because there's a known best practice to separate DB from source. And this proves out in practice, as there are also a few (not many, but a few) leaks where the hashes were leaked, but the source code was not, and the algorithm remains a mystery. (But this does not justify "security by algorithm obscurity", for exactly the reasons in schroeder's answer!) Apr 21 at 17:29
  • @RoyceWilliams fair enough
    – schroeder
    Apr 21 at 17:42
  • 1
    Just saying: A bit of obscurity doesn’t hurt. What’s bad is “security only by obscurity”.
    – gnasher729
    Apr 21 at 21:16
0

It is not common practice to vary the hashing algorithm. Common advice is to use a standard hashing function, such as PBKDF2, bcrypt, scrypt, or Argon2.

I have encountered several web applications that use non-standard hashing methods. This is usually the result of upgrading the hashing function. When a web application switches from MD5 hashing to PBKDF2 hashing, the easiest upgrade path is to calculate a PBKDF2 hash of the original MD5 hash, combining the two. These are inconvenient to crack, but offer no real security. Most of the time the algorithm can be determined. Remember, if somebody has access to the database with password hashes, you're already pretty screwed, so they probably can also view the hashing algorithm.

If the algorithm is sufficiently complex and the attacker doesn't know the hashing algorithm, the hashes are impossible to crack.

Instead of performing a custom algorithm, it is more common to use a secret key in the hashing process. Hashing functions use salt to get a different "algorithm" for each password. Some applications use a fixed hardcoded key, sometimes called a pepper, to make the hashing function specific to that application. Some applications encrypt the password hash before storing it in the database.

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.