0

How secure would it be if you applied custom algorithms (that you obviously wouldn't reveal to the public) to a hashed password? Like splitting up a hashed string, shuffling it around, possibly even do something else with it to further shuffle it. Then shuffle it back and compare the user's input to the original hash.

Then the next question, all of this shuffling is code, in a class, in a file. Can this not be reverse-engineered or somehow retrieved in some way?

schroeder
  • 125,553
  • 55
  • 289
  • 326
stefan
  • 1
  • 1
    Possible duplicate of [Why is security through obscurity not a good option ...?](https://security.stackexchange.com/questions/66552/why-is-security-through-obscurity-not-a-good-option-for-encryption) – Steffen Ullrich Jun 05 '19 at 10:35
  • Everywhere i read "It's bad" , "Dont invent your own" , "Use algorithms that are proven to be solid", but what i am suggesting is using a known proven to be solid algorithm, and change the string that comes out of that in a custom algorithm. I think i also read people saying it won't matter. I'd like to understand that IF adding a custom algorithm on top of a solid one adds no extra security, why? Because i honestly don't understand – stefan Jun 05 '19 at 11:10
  • You forgot to cite *"Why is security through obscurity not a good option"* - because this is the main point. If the security of your algorithm __relies__ on having a specific secret implementation then it is bad. If you just __add__ obscurity on top of something good then it is not a problem - see also [Security BY obscurity is horrible. Is security AND obscurity good?](https://security.stackexchange.com/questions/186781). But while it looks from the comment that your intention was to ask the latter one, your actual question was not clear about this and thus got interpreted in a different way. – Steffen Ullrich Jun 05 '19 at 11:27
  • @stefan Adding your own custom implementation on top of a known secure one could break the secure one. For example if you didn't know much about security you could hash your passwords using bcrypt and then decide to hash those hashes using MD5. You would think, hey I'm hashing it with BOTH bcrypt and MD5, it's doubly secure! But in reality you just made every single hash trivial to crack. And without a deep understanding of cryptography it can be hard to tell what could weaken security rather than strengthen it. – trallgorm Jun 05 '19 at 14:19
  • @trallgorm: how would it be trivial to crack double-hashed passwords, even if one hash is MD5? you would still have the bcrypt to get through, and even on the md5, it's a non-predictable input (bcrypt bytes, not a plain password). – dandavis Jun 06 '19 at 20:17
  • 1
    @dandavis disregard what I said, I was actually completely wrong in my comment. After reading up on it it may reduce entropy but it will not be trivial to crack by any means. Thanks for the catch. – trallgorm Jun 06 '19 at 20:48

0 Answers0