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 custom function which you put A => B, where output B is always the same for a given A. I'm aware that it wont be the best method, but please take that as is, a somewhat decent implementation.

Normally, if a hacker gained ONLY the database, they do their trick and manage 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.

Now, if I own a insignificant enough company not to get targeted specifically by hackers and implement my own 'extra sauce'1, 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 term this would be a worthless aproach, because what if you do become a more interesting target? Just do it right from the beginning. But what if you know you'll never be.

1e.g. I split the string in parts A & B, and concat them BAB. And then something better.

  • 1
    Could the downvoter please explain why, so I can correct my question?
    – Martijn
    Feb 7, 2020 at 12:15
  • As for the downvote: Unfortunately, some people use the downvote as "This is a bad idea" instead of "This is a bad question". There's nothing we can do to prevent that.
    – user163495
    May 27, 2021 at 12:37
  • 1
    Even if it's an insignificant site that will only live on your PC, do it right. It creates habit, and habits are difficult to change.
    – ThoriumBR
    May 27, 2021 at 12:43
  • Hi, thanks for your reply :) But this is a somewhat old question, I've just rephrazed it a bit better and checked the answers again :) But that kind of voting doesnt just happen here
    – Martijn
    May 27, 2021 at 12:43
  • @ThoriumBR Haha, one of my mottos at work is 'always turn on your blinker, even when noone is there. That way its a habit instead of something you need to think of"
    – Martijn
    May 27, 2021 at 12:44

5 Answers 5


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.

  • And how would my logic fair against how sites where made a decade ago? When the usage of sha was more common? I understand that having the same B everytime is wrong, and I understand why, but I wanted to know it specifically again a weaker algoritm.
    – Martijn
    Feb 7, 2020 at 12:17
  • Even when the usage of sha was more common it was wrong to use it without salt. Even the password algorithms before use of sha used a salt. ", but I wanted to know it specifically again a weaker algorithm." - why compare a recent secret but weak implementation against some old algorithm which should not have used in the past although it was. You are essentially asking if weak+obscurity is better then weak than and of course it is, only there is much less obscurity in your proposal as you imagine. Feb 7, 2020 at 15:47
  • If you could add that to your answer I'll mark it as answer :) Because that is more to what I was actually intending to ask :)
    – Martijn
    Feb 7, 2020 at 15:53
  • @Martijn: see updated answer. Feb 7, 2020 at 16:07

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.


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.


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.


You want some extra secret sauce on top of your hashing to prevent hackers from cracking your password in case the database is stolen, but not your code. That is actually a good idea.

However, adding your own homebrew extra hash step on top of things is not the way to do it. What you should do instead is one of these:

  • Use a pepper, an secret "extra salt" used for all passwords, that is not stored in the database. This is not an excuse to not use individual salt, though.
  • Encrypt the hashes before you store them in the database, and keep the key out of the database. This is the better option in my opinion, since it allows you to easily change the secret.

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.