2

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.

Community
  • 1
rakibtg
  • 145
  • 5
  • 4
    I believe this classifies as "rolling your own". Don't roll your own. (See [Schneier](https://www.schneier.com/blog/archives/2015/05/amateurs_produc.html) ) – Jonathan Sep 04 '15 at 12:35
  • I think, perhaps, you are describing the idea of a "salt", which is a commonly used technique. – schroeder Sep 04 '15 at 15:00
  • Or, are you considering a manual alteration of one or more characters ("I know that this MD5 hash should say F in the fourth character instead of the 6 that I put there")? – Andrew Leach Sep 04 '15 at 15:15

2 Answers2

9

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.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • Thanks a ton @Gilles. You helped me a lot to proper understand this thing. For password I use blowfish algorithm with a cost 12. I was intend to md5 a 'post id' and 'user id', when the user send an ajax request to the server for editing a comment they made under a post both in plain text version and a md5 version so that i could check if the user was inspected the post id or the user id, but then i found that it is too easy to brute force small integer values like 'user id' eg. 3454 or 'post id' like 2314. What would be your suggestion to me? Thanks again. – rakibtg Sep 04 '15 at 15:47
  • @meh-_- I don't understand. Why would you want to hash IDs? What attack are you trying to protect against? – Gilles 'SO- stop being evil' Sep 04 '15 at 15:48
  • Okay, 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. – rakibtg Sep 04 '15 at 15:54
  • 1
    @meh-_- A hash isn't going to help you here, MD5 or not. If someone wants to send back different input, they can inspect the source and find the ID, or they can inspect the source and find the hash, same difference. I'm not a web programmer, but I think what you need is a cookie containing either a session identifier or an encrypted token. I recommend that you post on [so], explain your architecture precisely and ask what information you need to pass. Don't start with the assumption that you need a hash, it's probably not the case. – Gilles 'SO- stop being evil' Sep 04 '15 at 17:56
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.

mcgyver5
  • 6,807
  • 2
  • 24
  • 45
  • Thanks, the scenario is likely different and there is so many entities not actual user, and i was trying to validate ID's of those. – rakibtg Sep 09 '15 at 13:59
  • I wondered if that was the case. Server-side checks are still needed to see if the "actual user" has permission to see or edit the resources they have requested. – mcgyver5 Sep 09 '15 at 14:35