1

I've read about why MD5, SHA1, and many other hashing functions are insecure, by a lot, but I'm thinking of doing a different approach.

It won't increase security, I'm aware of that, but I believe it can make cracking the hash much more difficult.

Let's say I hash some information as for example we'll use hellworld using MD5, and obtain 128bit hash:
fc5e038d38a57032085441e7fe7010b0

Now I'm thinking of disguising it to look as if it was SHA1, 160-bit hash. I could append padding to the start/end and much better, in between, at fixed/or based some logic.

So our output hash would look like this
fc5e038d38a57032fafe46a9085441e7fe7010b0

Which is actually formed like this
fc5e038d38a57032 + fafe46a9 + 085441e7fe7010b0

(I split the original hash right in the middle and added some (random) padding in the center.)

Would this make it more difficult to crack hashes as it would confuse attacker (assuming he cannot tell that it's a disguise)?

How would one crack this and find the orignal text? Without accessing any server files of course.

schroeder
  • 123,438
  • 55
  • 284
  • 319
das
  • 137
  • 4
  • 6
    When you know that the hashing function you're using is insecure and **you have both the intention and capability to modify your code** to the extent that it will support your trick in both the password set, change and verification routines, wouldn't that be same amount of effort as switching to any other password hashing scheme? Then you might as well do the right thing and **switch to [a well-known secure password hash function](https://security.stackexchange.com/q/211/77995) instead.** – HBruijn May 19 '19 at 13:23
  • Yes I am aware of it's insecurities, but the platform I'm using it, I'm limited to either md5 or sha1, so trying to make stuff a bit harder than is. More wondering if this practice could frustrate and make a bit more hard to crack compromised db. – das May 19 '19 at 13:32
  • 7
    Trying to "obscure" your hash function will not add any security whatsoever. –  May 19 '19 at 13:50
  • 1
    Yes, Im aware of that sir, stated it in the question. I'm more intersted in knowing how would one crack this, assuming he does not get any access to the server files. Not trying to argue whenever this is secure nor how would one secure information, but more insight of how would one try and deal this kind not-exact hash. – das May 19 '19 at 14:56
  • The _question_ part of this post is perfectly legitimate and doesn't warrant downvotes. The reason this post has so many downvotes is that you've come up with a partial answer: you're trying to get confirmation that what you're proposing is ok. The downvotes are because that part is completely wrong: it is not ok at all. – Gilles 'SO- stop being evil' May 19 '19 at 23:38
  • "It won't increase security I'm aware of that" and then "Would this make it more difficult to crack hashes". I think you answered yourself – Mr. E May 20 '19 at 02:53
  • 1
    Possible duplicate of [Why improvising your own Hash function out of existing hash functions is so bad](https://security.stackexchange.com/questions/33531/why-improvising-your-own-hash-function-out-of-existing-hash-functions-is-so-bad) –  May 20 '19 at 10:22

3 Answers3

3

You have basically created a custom hashing algorithm. If no one knows how your algorithm works and no one knows that it is trivially based on MD5, then it will be extremely difficult, if not impossible, to crack this hash. So, to answer your question directly about the hash, it is likely going to be uncracked without further knowledge.

The only real danger here, and it's not a trivial problem, is that if someone finds out how your algorithm works, then your efforts offer no protection at all.

This is known as "security by obscurity". It is secure as long as the attacker forever remains ignorant. One look at your algorithm and the hashes are equally crackable as MD5.

If you hide your front door, then someone with your keys will not be able to get in... Until they find your front door. It is always better to have better keys and locks.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 1
    “If no one knows (…) that it is MD5” This is completely unrealistic. Anybody looking to crack hashes and seeing a homemade thing with 16-byte (relevant) output will try MD5 before anything else. And even before seeing that the relevant output is 16 bytes long, they'll probably compare with a few MD5 hashes and notice the similarities. – Gilles 'SO- stop being evil' May 19 '19 at 23:36
  • That's entirely my point. – schroeder May 20 '19 at 06:41
  • 1
    Knowing you, it may well have been the point you meant to make. But that's not at all how it reads. – Gilles 'SO- stop being evil' May 20 '19 at 07:44
  • @Gilles There is no "homemade thing" here. The final string looks like a SHA1 hash. How would an attacker looking at `fc5e038d38a57032fafe46a9085441e7fe7010b0`know that it was MD5 or even homemade? – schroeder May 20 '19 at 08:47
  • Looking at a single hash? Probably not. But what's the threat model where an attacker can only ever see a single hash? The usual attacks (SQL or PHP injection) allow the attacker to dump the whole database, or at least to exfilter a moderately large but chosen subset. – Gilles 'SO- stop being evil' May 20 '19 at 09:57
1

What you're proposing is almost completely pointless, and probably counterproductive overall. It will protect you against some automatic scans that just look for standard formats, but not against someone who takes a few minutes to look at your system.

It won't increase security I'm aware of that, but I believe it can make cracking the hash much difficult.

These two statements are contradictory. It won't make cracking the hash more difficult, which is why it won't increase security. And anyway, why would you do this if it doesn't increase security?

how would one crack this and finds orignal text?

That's pretty easy: try a few different passwords, try the same password a few different times. That lets the attacker figure out what part depends on the password and what part doesn't. Notice that the actual hash is 16 bytes, check that it's MD5, and, depending on the attacker's mentality, either be happy to have spent so little time cracking that site or be disappointed that it was boringly unchallenging.

Without accessing to any server files of course.

If you assume that the attacker doesn't have access to server files, then they'll never see the password hashes. So you wouldn't need to ask this question. But you are right to ask this question, because attackers do get to see server files all the time (SQL injection, PHP vulnerabilities, insecurely stored backups, stolen admin credentials, …). The hypothesis that the attacker wouldn't see server files is not realistic and so you shouldn't base your analysis on it.

So forget about all this and read how to securely hash passwords. If your development platform doesn't have a proper password hashing function, seriously consider upgrading: that platform is clearly not well-suited to developing software that's accessible on the Internet. But if you're completely stuck, and all you have is SHA-1, look for an implementation of PBKDF2 on top of this SHA-1 primitive. If you can't find an existing, well-maintained implementation of PBKDF2, implement it yourself as a last resort.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 1
    I think you missed an important point. The final string is `fc5e038d38a57032fafe46a9085441e7fe7010b0`. That does not look like MD5 at all. That looks like SHA1, just as the OP desired. There are no underscores. The attacker would have to know that the hash had been tampered with and how before attempting MD5 cracking. – schroeder May 20 '19 at 08:45
  • Someone edited the OP's original string to add underscores. I have edited now differently. – schroeder May 20 '19 at 09:31
  • @schroeder Oh, ok. That was misleading. It doesn't change my answer though. Obviously someone looking at a _single_ hash is not likely to figure out that 4 bytes are irrelevant, but someone looking at the whole database will quickly figure out that some bytes are irrelevant. – Gilles 'SO- stop being evil' May 20 '19 at 09:56
  • The op tackles the problem of data in the database by devising the padding through a function relating to the password. So nothing in the database would tip off a viewer of the database. They would need the server side code. Hence my answer focusing on the obscurity angle. – schroeder May 20 '19 at 10:11
  • The only thing stored in the database is the sha-looking string. The op has basically created a custom hashing algorithm. – schroeder May 20 '19 at 10:14
  • @Gilles well the idea, is not to hand out string data that easily. along with that, adding salt when hashing, and add random padding, not necessarily 4 bytes in a single position, but let's say for example it would calculate (based on dataid/time and maybe other factor) where to insert each byte in 4 different positions (in total 4 bytes split across 32 bytes), it would make it a bit more difficult to understand how and where it was tempered,on top of that it would be different per data hash. , again this would be handled in a script,so access to server scripts is a must in order to decode – das May 21 '19 at 10:26
  • @das No, access to the scripts is _helpful_ but not _necessary_ for the attacker. Someone who knows what they're doing and can submit inputs and see the corresponding input can figure it out. Remember that you aren't defending against yourself: you're defending against anybody in the world who might take an interest (or who might be hired to break it). – Gilles 'SO- stop being evil' May 21 '19 at 10:43
  • @Gilles , you have a valid point, but I assume nobody would get hired to do so, as this is a small project and not some corporation project. Trying to gather some insight of how would one break this without having scripts, in case someone manages to steal database and tries just to sell this information or try to harm users who use this project. I thank you for your input! – das May 21 '19 at 11:51
  • @das I have given you some insight. This looks like the kind of thing _I_ might be able to figure out, depending on how much access I had and how much effort I was willing to put into it. And I'm not at all experienced in breaking stuff: my experience is all white hat stuff. – Gilles 'SO- stop being evil' May 21 '19 at 12:25
1

If an attacker is able to extract hashes from a database, they might sign up with the service so their password, pass123, is put through the hashing algorithm and inserted in the database.

This would allow them to try common hash functions and determine how the hash is being obscured:

  • Database hash 32250170a0dca92dfafe46b853ec9624f336ca24
  • SHA1 (pass123) aafdc23870ecbcd3d557b6423a8982134e17927e
  • MD5 (pass123) 32250170a0dca92d53ec9624f336ca24
Joe
  • 2,734
  • 2
  • 12
  • 22
  • 1
    If they have free access to the database, sure, this is one method of reverse engineering the algorithm. But it depends on that kind of access. – schroeder May 20 '19 at 10:44
  • I used helloworld as an example, by adding a salt it would make it a bit more difficult to understand which hash is correct, and detect any fluff, all this will be done via php script, as long as this script is not also compromised. The idea is basically avoid obtaining the plain text when database compromised, and mislead them as much as possible, and make them actually work(harder) to obtain data. – das May 21 '19 at 10:30