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.

  • 5
    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 instead. – HBruijn May 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 at 13:32
  • 6
    Trying to "obscure" your hash function will not add any security whatsoever. – MechMK1 May 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 at 14:56
  • 1
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.

  • 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 May 19 at 23:36
  • That's entirely my point. – schroeder May 20 at 6: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 May 20 at 7:44
  • @Gilles There is no "homemade thing" here. The final string looks like a SHA1 hash. How would an attacker looking at fc5e038d38a57032fafe46a9085441e7fe7010b0know that it was MD5 or even homemade? – schroeder May 20 at 8: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 May 20 at 9:57
2

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.

  • 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 at 8:45
  • Someone edited the OP's original string to add underscores. I have edited now differently. – schroeder May 20 at 9: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 May 20 at 9: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 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 at 10:14
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
  • 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 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 at 10:30

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.