MD5 brute force on a faulty hash?

Question

MD5 for passwords is considered insecure due to the ability to brute force and pick up the result.

But what if I change some characters of an MD5 hash and I keep a record of that change so that later I can match with that hash according to those changes?

Here is the question, is it also possible to brute force on a modified / faulty MD5 hash to match against an unknown string for a hacker?

Purpose: i found that it is relatively easy for a user to use tools like 'inspect elements' to change a "post_id" or a "user_id" in a web form so i was trying to hash those ID's and once the user submitted the form first of all i do match if the md5 of the user submitted ID's are matched with the md5 of those ID's pushed into the forms hidden element while generating the form.

Answer 1

There's a misconception or two in your question.

As a message (file, etc.) hash, MD5 is not insecure because of the “ability to brute force and pick up the result”. Cryptographic hashes are supposed to have three security properties:

1. One way: Given a hash, it is infeasible to find a message with that hash.
2. Integrity: given a message, it is infeasible to find another message with the same hash.
3. Collision resistance: it is infeasible to find two messages with the same hash.

The only property of MD5 that is now broken is the third one, collision resistance. It's possible to craft messages with the same hash. However, for a message that isn't specially crafted, it's still infeasible to find another message with the same hash. MD5 is nonetheless not recommended, partly because it's plausible that better attacks will be found soon that defeat integrity, and partly because many systems that primarily rely on integrity also rely on collision resistance against some high-level attacks.

Taking MD5 and modifying the output would not help with collision resistance in any way since a collision for MD5 would also be a collision for your modified hash. It wouldn't help with integrity either, for the same reason. So your proposal can do nothing against the known defects of MD5.

If you modify an MD5 hash, then it could become harder to find a message with the hash. But only if the transformation you do is hard to invert! For example, if you do some fixed transformation like flip a few bits, that's useless. If you encrypt the hash, that could do it — or not: it depends on the security property that you want to achieve. Remember that the one way property for MD5 is not known to be broken.

So what security property do you want to achive?

If you're using MD5 it as a password hash, then MD5 is not your only problem, or your main problem. For a password hash, brute force searches are a concern. None of the usual message hashes are suitable as password hashes, because they're fast. Password hashes must be slow, precisely to make brute force searches harder — they hit the attacker harder than the legitimate user, because the attacker must try millions of possibilities. Tweaking MD5 cannot possibly help there. If you're hashing passwords, forget about MD5, even if you found it used in one of the millions of broken PHP apps out there. To hash passwords, use PBKDF2, bcrypt or scrypt. If you're even thinking of using anything other than one of these three, read How to securely hash passwords? first — all of it.

For a password hash, the idea of adding a secret component to the hash function is called a pepper. A pepper involves a secret key and some actual cryptography — “change some characters” would be so easy to reverse that it's useless as a pepper. The normal way to include a pepper is to add it to the password and to the salt when calculating the hash. And remember that the pepper must be secret — if it's in your application source, or in the same database or the same backup disks as the password database, it's useless.

Answer 2

The problem you are trying to solve is users manipulating hidden form field values.

Like @Gilles said, these values should be controlled in the session (server side). Server-side checks are needed to verify that the given user has permission to change a given post. In other words, the hidden field "user_id" should not exist! Value for user ID will be known in session.