Using a home-brewed hash for passwords for a insignificant website

Question

First off: I do not, nor intend to, use a home brew hash functionality, ever. I'm aware why one shouldn't do that and have read enough topics about it to know it's foolish to do.

I understand that I am no expert at the subject and that those who are could find and abuse a vulnerability in my own made algorithm and could use those conclusions to break my stored hashed passwords more easily than a more robust standard encryption.

The thing I cant wrap my head around is the following: If you assume a function which you put A in, always outputs B, where B is always the same. I'm aware that that's not the best, but please take that as is as an 'proper' algorithm for comparison.

If a hacker has a database, does its thing and managed to restore an amount of passwords from it. If they have a bot running, or download/generic hack/buy some hashed passwords, the hacker can repeat the standard tricks to reverse them.

If I own a insignificant enough company not to get targeted specifically by hackers and implement my own 'extra sauce'¹, all the 'driveby' variants of using tricks no longer work and thus would be safer.

Is there/what is the flaw in my logic? Long them this would be a worthless aproach, becasue what if you do get bigger? Just do it right from the beginning. But what if you know you'll never be.

_{¹e.g. I split the string in parts A & B, and concat them BAB.}

Answer 1

The first flaw in your logic is that no sane password hash algorithm has the property you describe, i.e "If you assume a function which you put A in, always outputs B, where B is always the same.". Instead proper hashing includes a random salt so that same passwords (A) result in a different hash (B). With a long enough salt which is also actually random it is practically impossible for an attacker to create a database of mappings since this would take too long and would also be too big. Note that even if in the past some implementations simply hashed the password with MD5 or SHA1 it was wrong in the past too. Already the POSIX crypt function from ages ago required the use of a salt.

The second flaw in your logic is that you consider your secret algorithm more secret than it actually is in practice. All the hacker needs to do is to compromise your site and steal not only the weakly hashed passwords but also the parts of the code which do the secret password hashing, which is very likely on the same site. Then they can use your own weak algorithm to brute force the passwords in the database. So in essence your idea of combining a weak algorithm with obscurity will fall down to being only weak since the obscurity part does not really work.

Note that such a compromise is not unlikely even if the site seems to be unimportant. Attackers not only compromise sites in order to steal important things but also to use trusted hosts as starting points for further attacks. And less important sites are often less secured so compromising these is comparably easy. Getting access to the hashed passwords and to the hash algorithm is then an unintended but maybe welcome side effect.

Answer 2

This might make sense under the assumption that an attacker doesn't know how your algorithm works. Unfortunately that isn't a realistic assumption.

Sometimes the attacker is an insider (in fact, insiders are responsible for roughly 25% of all breaches). Sometimes an insider accidentally publishes private data (also responsible for roughly 25% of all breaches). Sometimes an external attacker gets access to not just your database but also your code base.

In all of the above cases your magic sauce is completely useless. A strong hash function protected by a salt is very resistant to brute force attacks. Even more so if you add in a pepper which is not stored directly in your code base. Conveniently, such tools are also well supported and easy to use these days - much easier than writing your own magic sauce.

As a result there really just isn't any good reason to write your own magic sauce.

Answer 3

A hash function is not reversible. The only real "trick" is for an attacker to brute force and/or create a table lookup of all the A -> B outcomes (sort by B).

Using salt is a side issue. Salt is simply additional information that is concatenated onto the input A. The hashing algorithm stays the same.

If you added another hash function in series that is the same size or larger, it would be more secure against any potential mathematical flaws in an individual algorithm. Essentially, running the same hashing algorithm X times is more secure, because it makes brute forcing take X times longer. If multiple algorithms are used it reduces the likelyhood that a non-bruteforce shortcut can be used.

Your own hash function would need to satisfy the same benchmarks that professional ones do: have a uniform statistical distribution of values. You should be able to run your function and find that no value or value ranges are output more than others. Any value colossians must be unpredictable byba simpler mathematical function.

I'm not sure what your example homebrew function is, so I can't comment further on that yet.

Answer 4

If they managed to hack your database and steal your password hashes, there is a good chance they can get to your source code and figure out how you performed your magic. You should never rely on security by obscurity.

Now imagine they know your trick and will try cracking attempts on it. Fat chance that you managed to make a password hashing function that's better protected against GPU parallelization than the functions we have. Just use best practices. And the cool thing is that most programming languages have these top-knotch functions ready to go these days. Don't roll your own crypto.