289

Someone told me that he has seen software systems that:

  1. retrieve MD5 encrypted passwords from other systems;
  2. decrypt the encrypted passwords and
  3. store the passwords in the database of the system using the systems own algorithm.

Is that possible? I thought that it wasn't possible / feasible to decrypt MD5 hashes.

I know there are MD5 dictionaries, but is there an actual decryption algorithm?

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
John B
  • 20,062
  • 35
  • 120
  • 170
  • Related: http://stackoverflow.com/questions/2717950/how-can-it-be-impossible-to-decrypt-an-md5-hash – David Z Mar 18 '12 at 21:47
  • 282
    MD5 is a digest algorithm. Think of it as converting a cow into a steak. Now try to reverse that. – Mechanical snail Jan 07 '13 at 23:42
  • MD5 is a **one way** Hash function. Sorry! – Davie Sep 24 '09 at 13:26
  • 9
    Reverting the MD5 would yield multiple passwords also. – Carles Company Sep 24 '09 at 13:29
  • 3
    here's some papers on [MD5 collisions](http://scholar.google.com/scholar?q=MD5+Collision&hl=en&btnG=Search) and [here's](http://stachliu.com/research_collisions.html) an [MD5 Collision Generator by Patrick Stach](http://www.stachliu.com/md5coll.c) on [CodePad](http://codepad.org/ZupMIuSc) based on [Xiaoyun Wang and Hongbo Yu's](http://210.40.7.166/crypto/confer/eurocrypt2005.pdf#page=32) paper: [How to break MD5 and other Hash Functions](http://scholar.google.com/scholar?cluster=151399481987648698&hl=en) Here's a [visualization](http://www.mathstat.dal.ca/~selinger/md5collision/) on [an MD5 Co – pageman Aug 06 '09 at 19:29
  • MD5 collisions are not really relevant for password storage, though. – Paŭlo Ebermann Sep 04 '11 at 17:51
  • 1
    No, there are dictionaries as you say, but no way to decrypt MD5 – Tom Neyland Aug 06 '09 at 19:28
  • I wonder what if I know the original value before hash, like abcdefg, and I also have the value after hash and add a salt, for example, FFEA56E6F4 (just for example..). Is that possible to figure out the algorithm to do the hash? – Arst Jul 01 '13 at 02:48
  • 5
    @Arst from what I understand, yes, but only if you had ALOT of those. And even if you did, you wouldn't be able to go in reverse, because the algorithm purposefully loses information. – Jordan Aug 14 '13 at 17:46
  • 10
    @mechanicalsnail given that analogy, one could make a full perfect clone from the DNA on the steak. :)) – Trimikha Valentius Mar 11 '15 at 10:24
  • 10
    @TrimikhaValentius MD5 is a digestive algorithm. Think of it as eat steak > digestion > output. Now try to reverse that. – user4157124 Nov 17 '17 at 20:48

24 Answers24

461

No. MD5 is not encryption (though it may be used as part of some encryption algorithms), it is a one way hash function. Much of the original data is actually "lost" as part of the transformation.

Think about this: An MD5 is always 128 bits long. That means that there are 2128 possible MD5 hashes. That is a reasonably large number, and yet it is most definitely finite. And yet, there are an infinite number of possible inputs to a given hash function (and most of them contain more than 128 bits, or a measly 16 bytes). So there are actually an infinite number of possibilities for data that would hash to the same value. The thing that makes hashes interesting is that it is incredibly difficult to find two pieces of data that hash to the same value, and the chances of it happening by accident are almost 0.

A simple example for a (very insecure) hash function (and this illustrates the general idea of it being one-way) would be to take all of the bits of a piece of data, and treat it as a large number. Next, perform integer division using some large (probably prime) number n and take the remainder (see: Modulus). You will be left with some number between 0 and n. If you were to perform the same calculation again (any time, on any computer, anywhere), using the exact same string, it will come up with the same value. And yet, there is no way to find out what the original value was, since there are an infinite number of numbers that have that exact remainder, when divided by n.

That said, MD5 has been found to have some weaknesses, such that with some complex mathematics, it may be possible to find a collision without trying out 2128 possible input strings. And the fact that most passwords are short, and people often use common values (like "password" or "secret") means that in some cases, you can make a reasonably good guess at someone's password by Googling for the hash or using a Rainbow table. That is one reason why you should always "salt" hashed passwords, so that two identical values, when hashed, will not hash to the same value.

Once a piece of data has been run through a hash function, there is no going back.

Adam Batkin
  • 51,711
  • 9
  • 123
  • 115
  • 26
    however, there are more collisions than originally thought in the MD5 hash space. It is no longer considered optimal as the best hash for passwords. – Cheeso Aug 06 '09 at 19:29
  • And that is why the NIST is running a competition to determine a replacement for the SHA-1 and SHA-2 algorithms, all of which are more secure than MD5. MD5 should not be used in new security-critical applications. It is not clear that SHA-1 is safe. SHA-2 is recommended until SHA-3 is available. – Jonathan Leffler Aug 07 '09 at 00:39
  • 14
    Since most passwords are shorter than the MD5 hash, there is usually only one password for each hash. (And finding one, even if it is not the original one, is enough to access the account.) The point of being one-way function is not *there are multiple different preimages, so we can't know which one was the original one*, but *it is really hard to find even one original value*. – Paŭlo Ebermann Sep 04 '11 at 17:49
  • 1
    There aren't an infinite number of inputs to MD5 - input messages are limited to 2^64 bits. – Nick Johnson Sep 05 '11 at 02:50
  • 2
    @Nick: Actually, RFC1321 explicitly says: "The algorithm takes as input a message of arbitrary length" – Adam Batkin Sep 05 '11 at 15:09
  • 1
    Oops, you're right - "A 64-bit representation of b (the length of the message before the padding bits were added) is appended to the result of the previous step. In the unlikely event that b is greater than 2^64, then only the low-order 64 bits of b are used". Nice bit of understatement there, too. – Nick Johnson Sep 06 '11 at 01:10
  • 1
    This answer is actually partly incorrect. While `password` and `CPfvwl#qr*w4*96C@&@xj$T2ZggJC%` and an infinite number of other inputs might give the same hash, we're not left with zero ways of figuring out the original as the answer suggests. This sort of obvious test (and, to automate it, testing to see whether a candidate plaintext matches the statistics of expected plaintexts) is used all the time in determining whether regular ciphertext has been cracked yet or not. – Olathe Feb 19 '13 at 22:56
  • 7
    @Olathe - I'm not sure I agree. Given a hash, it is *generally* impossible to determine (with 100% certainty) the original input. There are (usually) an infinite number of inputs that produce every possible (hashed) output. I said *generally* because, if you know (for example) that you are looking for a string of ASCII characters, and it's less than, say, 12 bytes, it is probable that there is only one input that produces a given output. But there are always going to be collisions (infinite), and unless you have some external constraint (like in my example) you will never know which is right – Adam Batkin Feb 20 '13 at 03:58
  • 2
    @Adam Batkin, you're right, but I don't mean 100% certainty. Cipher breaking can't be done with 100% certainty. The sender might have meant random gibberish rather than English plaintext using the same key that decrypts other English plaintexts, but the probability of the English is very close to 100%. Similarly, when choosing between a long UTF-8 Japanese poem password and gibberish strings, the probability of the poem is near 100%. This can be done using after-the-fact probabilities rather than prechosen constraints. It obviously can't be done in general, but it is still quite useful. – Olathe Apr 26 '13 at 11:17
  • 1
    Just salting passwords is not enough to make them secure, a password hash (that includes the use of a reasonably large salt, for sure) such as bcrypt should be used instead. – Maarten Bodewes Sep 18 '18 at 21:35
161

You can't - in theory. The whole point of a hash is that it's one way only. This means that if someone manages to get the list of hashes, they still can't get your password. Additionally it means that even if someone uses the same password on multiple sites (yes, we all know we shouldn't, but...) anyone with access to the database of site A won't be able to use the user's password on site B.

The fact that MD5 is a hash also means it loses information. For any given MD5 hash, if you allow passwords of arbitrary length there could be multiple passwords which produce the same hash. For a good hash it would be computationally infeasible to find them beyond a pretty trivial maximum length, but it means there's no guarantee that if you find a password which has the target hash, it's definitely the original password. It's astronomically unlikely that you'd see two ASCII-only, reasonable-length passwords that have the same MD5 hash, but it's not impossible.

MD5 is a bad hash to use for passwords:

  • It's fast, which means if you have a "target" hash, it's cheap to try lots of passwords and see whether you can find one which hashes to that target. Salting doesn't help with that scenario, but it helps to make it more expensive to try to find a password matching any one of multiple hashes using different salts.
  • I believe it has known flaws which make it easier to find collisions, although finding collisions within printable text (rather than arbitrary binary data) would at least be harder.

I'm not a security expert, so won't make a concrete recommendation beyond "Don't roll your own authentication system." Find one from a reputable supplier, and use that. Both the design and implementation of security systems is a tricky business.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Thanks for answering, is there any other method for saving passwords that can be reversed in future time. – akano1 Sep 24 '09 at 13:28
  • 2
    Yes, there are other methods, but you need to understand what Jon said above - 'you shouldn't email them their password - that's sensitive information which might remain sensitive.' - at the lowest level, emails can be intercepted and sensitive information can be retrieved. A password should stay as secure as possible - usually by keeping it as a hash only in a database. – Daniel May Sep 24 '09 at 13:30
  • 3
    And also the fact that if the password can be reversed, that means anyone who gets access to your database can get at users' passwords. *Not* a good idea. One way passwords should be the norm; only keep the real password (even encrypted) if you absolutely *have* to (e.g. to authenticate with another system which doesn't have anything token-based). – Jon Skeet Sep 24 '09 at 13:33
  • 24 hours is a lot of time. I would reduce that to 10 minutes or so. That would be enough even if you first need to login to your e-mail account. – Gumbo Sep 24 '09 at 13:43
  • @Gumbo: When would you start the timer though? Giving only 10 minutes doesn't allow for server-lag, what if the email wasn't sent instantly? – Daniel May Sep 24 '09 at 13:55
  • 1
    I've seen antispam-measures where the receivers webserver denies an incoming mail just to wait for the sender's mailserver to retry (spambots usually only try once). That could easily exceed your 10 minute timeout. – sisve Sep 24 '09 at 13:56
  • @Gumbo making it one-time-use is more important than the timeframe. If there is a man in the middle or someone with access to the user's email, it's a simple race with no advantage to either party. We should assume we lose - the next best thing is knowing right away something is wrong because the one-time-use password already got used. – Rex M Sep 24 '09 at 14:02
  • This reminds me of a story I heard about a guy who never bothered with passwords at all, he just got the recovery systems to generate a fresh one every time he needed to log in. –  Sep 24 '09 at 14:56
  • 1
    @ravisoni: That's finding *a* value which has the same hash, presumably via brute force or lookup tables. There's no guarantee that it's the original plaintext value. – Jon Skeet Jan 12 '13 at 17:10
  • @JonSkeet but i always use this site for getting any unknown password values and this is always right... – Ravi Soni Jan 12 '13 at 17:57
  • 5
    @ravisoni: What do you mean by "right" here? If the password is unknown, you can't know whether the one revealed is the original one or not. But the point is that one way hashes like MD5 *by definition* lose information. The fact that sites like this can come up with *a* matching password is just good evidence of MD5 being a bad algorithm to use for security reasons. – Jon Skeet Jan 12 '13 at 18:58
  • @KiranRS: Well that will find - in some cases - *a* value which has the same hash. That doesn't mean it's the one which was originally used, and in many cases it won't find anything. (From the page: "Our database contains over 15,186,881 unique MD5 hashes." That's really not very many.) – Jon Skeet Mar 26 '15 at 07:56
55

Technically, it's 'possible', but under very strict conditions (rainbow tables, brute forcing based on the very small possibility that a user's password is in that hash database).

But that doesn't mean it's

  • Viable
    or
  • Secure

You don't want to 'reverse' an MD5 hash. Using the methods outlined below, you'll never need to. 'Reversing' MD5 is actually considered malicious - a few websites offer the ability to 'crack' and bruteforce MD5 hashes - but all they are are massive databases containing dictionary words, previously submitted passwords and other words. There is a very small chance that it will have the MD5 hash you need reversed. And if you've salted the MD5 hash - this won't work either! :)

The way logins with MD5 hashing should work is:

During Registration:
 User creates password -> Password is hashed using MD5 -> Hash stored in database

During Login:
User enters username and password -> (Username checked) Password is hashed using MD5 -> Hash is compared with stored hash in database

When 'Lost Password' is needed:

2 options:

  • User sent a random password to log in, then is bugged to change it on first login.

or

  • User is sent a link to change their password (with extra checking if you have a security question/etc) and then the new password is hashed and replaced with old password in database
Chris Huang-Leaver
  • 6,059
  • 6
  • 41
  • 67
Daniel May
  • 8,156
  • 1
  • 33
  • 43
  • 1
    I've got a few nitpicks. Rainbow tables are not brute forcing. There are actually programs and sites that do brute force (very simple) passwords of a few characters (generally they just loop over a few hours or days, and you can fill in a hash and hope it comes up in the loop). And unfortunately, given the lack of quality of many passwords, the chance that one pops up is not "a very small chance". – Maarten Bodewes Sep 18 '18 at 22:58
  • I have to interject: Reversing MD5 is not malicious by nature. How you use this ability is what determines malice or good intent. If some one figured out how to reverse it and shared that with the world, they could win a nobel prize or something. Don't EVER be afraid to try and reverse engineer ANYTHING if that is what you wanna do. That is how we all get better. But if you find a reverse to MD5 and then use it for personal gain, then yes, you are being malicious. – Robert Cotterman Nov 16 '20 at 15:57
32

Not directly. Because of the pigeonhole principle, there is (likely) more than one value that hashes to any given MD5 output. As such, you can't reverse it with certainty. Moreover, MD5 is made to make it difficult to find any such reversed hash (however there have been attacks that produce collisions - that is, produce two values that hash to the same result, but you can't control what the resulting MD5 value will be).

However, if you restrict the search space to, for example, common passwords with length under N, you might no longer have the irreversibility property (because the number of MD5 outputs is much greater than the number of strings in the domain of interest). Then you can use a rainbow table or similar to reverse hashes.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • 1
    I would add that finding another value that hashes to the same output is called a "collision". This is the most common method of breaking MD5-hashed systems. – Nicole Aug 06 '09 at 19:29
  • 5
    @Renesis, finding data that hashes to a previously known value is called a "preimage", actually, and it's much, _much_ harder than just a collision. No preimage attack has yet been demonstrated against MD5, but collision attacks have been used. – bdonlan Aug 06 '09 at 22:08
  • The point of hash functions (when used for password storage) is not that there are lots of possible passwords which give the same hash (there are, but most of them are longer than the hash itself), but that it is hard to find even one of them (which would be enough to access the system). And yes, because of rainbow tables you don't use unsalted hashes. And because of the small password space, you'll use a slow hash (like bcrypt or scrypt) instead of a fast one (like MD5/SHA-*/....) – Paŭlo Ebermann Sep 04 '11 at 17:57
  • 1
    To be technical, you can't perform MD5 with certainty, because the hardware might have malfunctioned. In the same way, you may not be able to be certain that the password was `password` rather than all the other infinite inputs that produce the same hash but which all look quite random, but you can be close enough. – Olathe Feb 19 '13 at 23:03
  • The pigeonhole principle applies of course, but it is still *computationally infeasible* to find a second input that hashes to a certain value, e.g. a hash over a normal password. If you find an X that hashes to a given H(X) then you can be certain that X is the correct input. *This makes the whole first section of this answer and most of the rest incorrect.* – Maarten Bodewes Sep 18 '18 at 21:33
13

Not possible, at least not in a reasonable amount of time.

The way this is often handled is a password "reset". That is, you give them a new (random) password and send them that in an email.

Matthew Groves
  • 25,181
  • 9
  • 71
  • 121
12

You can't revert a md5 password.(in any language)

But you can:

give to the user a new one.

check in some rainbow table to maybe retrieve the old one.

Nettogrof
  • 2,116
  • 2
  • 15
  • 22
  • 1
    Nix the rainbow table idea. If you're salting -- and you should be -- then it wouldn't work, anyhow. – Steven Sudit Sep 24 '09 at 13:51
  • 1
    @StevenSudit If they are still using MD5 to hash passwords instead of using a strong password hash, then you cannot *assume* they are using a salt. Maybe they do, probably they don't. – Maarten Bodewes Sep 19 '18 at 09:41
10

No, he must have been confused about the MD5 dictionaries.

Cryptographic hashes (MD5, etc...) are one way and you can't get back to the original message with only the digest unless you have some other information about the original message, etc. that you shouldn't.

Robert Greiner
  • 29,049
  • 9
  • 65
  • 85
8

Decryption (directly getting the the plain text from the hashed value, in an algorithmic way), no.

There are, however, methods that use what is known as a rainbow table. It is pretty feasible if your passwords are hashed without a salt.

Sinan Taifour
  • 10,521
  • 3
  • 33
  • 30
7

MD5 is a hashing algorithm, you can not revert the hash value.

You should add "change password feature", where the user gives another password, calculates the hash and store it as a new password.

Svetlozar Angelov
  • 21,214
  • 6
  • 62
  • 67
7

There's no easy way to do it. This is kind of the point of hashing the password in the first place. :)

One thing you should be able to do is set a temporary password for them manually and send them that.

I hesitate to mention this because it's a bad idea (and it's not guaranteed to work anyway), but you could try looking up the hash in a rainbow table like milw0rm to see if you can recover the old password that way.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
6

See all other answers here about how and why it's not reversible and why you wouldn't want to anyway.

For completeness though, there are rainbow tables which you can look up possible matches on. There is no guarantee that the answer in the rainbow table will be the original password chosen by your user so that would confuse them greatly.

Also, this will not work for salted hashes. Salting is recommended by many security experts.

Dinah
  • 52,922
  • 30
  • 133
  • 149
  • **Incorrect**. If a match is found then it is certain that it will be the original password. If this wasn't the case then it would be possible to generate collisions given any H(X) where X is an message without a predefined structure determined by the adversary. It is computationally infeasible to find such a collision for a cryptographically secure hash function, even if it is a broken hash function such as MD5. – Maarten Bodewes Sep 18 '18 at 21:40
  • @MaartenBodewes: "If a match is found then it is certain that it will be the original password." I can't see how that's the case, if we assume unlimited lengths of passwords. I'd say it's **extremely likely** to be the original password, but it doesn't *have* to be. The fact that there are more possible passwords than MD5 hashes mean it *must* be possible for there to be two passwords with the same hash. Just because it's computationally infeasible to *find* such collisions doesn't mean they don't exist. Or have I misunderstood you? – Jon Skeet Sep 19 '18 at 08:47
  • @JonSkeet If it is computationally infeasible to find a collision *on purpose* then finding one *by chance* is equally unlikely or worse. Due to the limited output space of MD5 and the birthday problem the chance that you will find a collision is about 1 in 2^64 (i.e. about half of the output space) - and that's after matching about 2^64 hashes. And this doesn't even consider that the message probably needs to be small and have a specific format to be considered a password. Most passwords have an entropy considerably below 2^64 bits. – Maarten Bodewes Sep 19 '18 at 09:26
  • 2
    @MaartenBodewes: But there's a big difference between "astronomically unlikely" and "impossible". Your statement about it being *certain* that it's the right password is overly strong, IMO. That suggests a mathematical certainty that isn't present. – Jon Skeet Sep 19 '18 at 09:28
  • You can also guess a 2^128 bit AES key in one go. It is "just" extremely unlikely. Cryptography relies on these kind of odds. For all practical purposes, if you find an input message / password, it will be the one you were looking for. That it is *theoretically possible* to find another input message is nice, but for this question *on StackOverflow* there is no need to consider it. And rainbow tables are only filled with possible passwords. They won't contain enough data there to be ever even a chance of a collision (they would either unknowingly overwrite the mapping or become famous). – Maarten Bodewes Sep 19 '18 at 09:31
6

No, it is not possible to reverse a hash function such as MD5: given the output hash value it is impossible to find the input message unless enough information about the input message is known.

Decryption is not a function that is defined for a hash function; encryption and decryption are functions of a cipher such as AES in CBC mode; hash functions do not encrypt nor decrypt. Hash functions are used to digest an input message. As the name implies there is no reverse algorithm possible by design.

MD5 has been designed as a cryptographically secure, one-way hash function. It is now easy to generate collisions for MD5 - even if a large part of the input message is pre-determined. So MD5 is officially broken and MD5 should not be considered a cryptographically secure hash anymore. It is however still impossible to find an input message that leads to a hash value: find X when only H(X) is known (and X doesn't have a pre-computed structure with at least one 128 byte block of precomputed data). There are no known pre-image attacks against MD5.

It is generally also possible to guess passwords using brute force or (augmented) dictionary attacks, to compare databases or to try and find password hashes in so called rainbow tables. If a match is found then it is computationally certain that the input has been found. Hash functions are also secure against collision attacks: finding X' so that H(X') = H(X) given H(X). So if an X is found it is computationally certain that it was indeed the input message. Otherwise you would have performed a collision attack after all. Rainbow tables can be used to speed up the attacks and there are specialized internet resources out there that will help you find a password given a specific hash.

It is of course possible to re-use the hash value H(X) to verify passwords that were generated on other systems. The only thing that the receiving system has to do is to store the result of a deterministic function F that takes H(X) as input. When X is given to the system then H(X) and therefore F can be recalculated and the results can be compared. In other words, it is not required to decrypt the hash value to just verify that a password is correct, and you can still store the hash as a different value.

Instead of MD5 it is important to use a password hash or PBKDF (password based key derivation function) instead. Such a function specifies how to use a salt together with a hash. That way identical hashes won't be generated for identical passwords (from other users or within other databases). Password hashes for that reason also do not allow rainbow tables to be used as long as the salt is large enough and properly randomized.

Password hashes also contain a work factor (sometimes configured using an iteration count) that can significantly slow down attacks that try to find the password given the salt and hash value. This is important as the database with salts and hash values could be stolen. Finally, the password hash may also be memory-hard so that a significant amount of memory is required to calculate the hash. This makes it impossible to use special hardware (GPU's, ASIC's, FPGA's etc.) to allow an attacker to speed up the search. Other inputs or configuration options such as a pepper or the amount of parallelization may also be available to a password hash.

It will however still allow anybody to verify a password given H(X) even if H(X) is a password hash. Password hashes are still deterministic, so if anybody has knows all the input and the hash algorithm itself then X can be used to calculate H(X) and - again - the results can be compared.

Commonly used password hashes are bcrypt, scrypt and PBKDF2. There is also Argon2 in various forms which is the winner of the reasonably recent password hashing competition. Here on CrackStation is a good blog post on doing password security right.

It is possible to make it impossible for adversaries to perform the hash calculation verify that a password is correct. For this a pepper can be used as input to the password hash. Alternatively, the hash value can of course be encrypted using a cipher such as AES and a mode of operation such as CBC or GCM. This however requires the storage of a secret / key independently and with higher access requirements than the password hash.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
4

MD5 is considered broken, not because you can get back the original content from the hash, but because with work, you can craft two messages that hash to the same hash.

You cannot un-hash an MD5 hash.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
  • 4
    By design, all same-length hashes suffer from collisions. It's unavoidable when restraining variable-length data. MD5 is considered obsolete for its rate of collisions, not for the fact of colliding. – Jonathan Lonowski Aug 06 '09 at 19:46
  • 1
    MD5 is considered broken because of the proven possibility of constructing inputs that collide. – Ned Batchelder Aug 06 '09 at 21:45
4

There is no way of "reverting" a hash function in terms of finding the inverse function for it. As mentioned before, this is the whole point of having a hash function. It should not be reversible and it should allow for fast hash value calculation. So the only way to find an input string which yields a given hash value is to try out all possible combinations. This is called brute force attack for that reason.

Trying all possible combinations takes a lot of time and this is also the reason why hash values are used to store passwords in a relatively safe way. If an attacker is able to access your database with all the user passwords inside, you loose in any case. If you have hash values and (idealistically speaking) strong passwords, it will be a lot harder to get the passwords out of the hash values for the attacker.

Storing the hash values is also no performance problem because computing the hash value is relatively fast. So what most systems do is computing the hash value of the password the user keyed in (which is fast) and then compare it to the stored hash value in their user database.

Kage
  • 395
  • 1
  • 3
  • 9
  • There is nothing much wrong with this answer except that the speed of the hash function *is very much a problem* because most passwords are not secure enough and allow an adversary to perform a dictionary attack. For that reason slow password hash functions are used instead of fast cryptographically secure hash functions. – Maarten Bodewes Sep 18 '18 at 21:44
4

You can find online tools that use a dictionary to retrieve the original message.

In some cases, the dictionary method might just be useless:

  • if the message is hashed using a SALT message
  • if the message is hash more than once

For example, here is one MD5 decrypter online tool.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
davitz38
  • 377
  • 1
  • 2
  • 9
  • *Rainbow tables* - not dictionary attacks - are useless if a salt is used. Hashing more than once - without a salt - still allows rainbow tables, although finding a *pre-existing* one online is certainly less likely. – Maarten Bodewes Sep 19 '18 at 10:33
2

The only thing that can be work is (if we mention that the passwords are just hashed, without adding any kind of salt to prevent the replay attacks, if it is so you must know the salt)by the way, get an dictionary attack tool, the files of many words, numbers etc. then create two rows, one row is word,number (in dictionary) the other one is hash of the word, and compare the hashes if matches you get it...

that's the only way, without going into cryptanalysis.

berkay
  • 3,907
  • 4
  • 36
  • 51
2

The MD5 Hash algorithm is not reversible, so MD5 decode in not possible, but some website have bulk set of password match, so you can try online for decode MD5 hash.

Try online :

MD5 Decrypt

md5online

md5decrypter

Girish Patidar
  • 354
  • 4
  • 14
  • Yeah, but this is already covered by the question as in the phrase "I know that there are dictionaries". Just pointing out the dictionaries therefore doesn't count as an answer. – Maarten Bodewes Sep 18 '18 at 21:54
2

Yes, exactly what you're asking for is possible. It is not possible to 'decrypt' an MD5 password without help, but it is possible to re-encrypt an MD5 password into another algorithm, just not all in one go.

What you do is arrange for your users to be able to logon to your new system using the old MD5 password. At the point that they login they have given your login program an unhashed version of the password that you prove matches the MD5 hash that you have. You can then convert this unhashed password to your new hashing algorithm.

Obviously, this is an extended process because you have to wait for your users to tell you what the passwords are, but it does work.

(NB: seven years later, oh well hopefully someone will find it useful)

user3710044
  • 2,261
  • 15
  • 15
  • Thanks for the reply. However I'm going to "1 up" you :) I can't remember if I actually did this, but in theory it should work. Instead of waiting for every single user to login so that we can re-encrypt their password, you can simply encrypt the hashed version of their password. So every password will be MD5 hashed, and then encrypted. Just updated the password check to do the same and the user data should be safe without requiring user intervention. – John B Sep 14 '16 at 01:16
  • One more caveat to my comment above. I'm not an expert on encryption, so I'm not sure if there are any further security implications of this. For example, encrypting weak passwords that are weakly hashed before being encrypting could potentially compromise the security of the encryption (maybe use another salt too?). Also, you may have backups floating around with those MD5 hashed passwords. Probably better to do a full invalidation of all existing passwords when doing this type of upgrade. – John B Sep 14 '16 at 01:19
  • Cryptographers worry about double encryption, but I think they've only found trivial cases where it's a problem. But I don't think it's useful in this case because MD5 is still secure for (not too long, text) passwords. Still, double hashing could be useful if the previous developer forgot to add salt, otherwise, I can't think of a case where you wouldn't have to tell everyone the passwords should be considered pwned. Hopefully, your backups don't get lost, and are encrypted anyway. – user3710044 Sep 14 '16 at 01:36
1

No, it cannot be done. Either you can use a dictionary, or you can try hashing different values until you get the hash that you are seeking. But it cannot be "decrypted".

Vilx-
  • 104,512
  • 87
  • 279
  • 422
  • i saw this website which reverses the md5 into the original text : http://md5.gromweb.com/ . How is it possible then? – samach Apr 20 '15 at 08:41
  • 2
    @samach321 - Easy: they have a DB of hashed strings. Whatever you enter in their "Convert a string to a MD5 hash" box gets added to the DB. Try getting an MD5 hash from another source and enter that. Unless it's something that is in their DB, you won't get a result. – Vilx- Apr 20 '15 at 08:48
  • It's called a Rainbow Table, btw. From Wikipedia: "A rainbow table is a precomputed table for caching the output of cryptographic hash functions, usually for cracking password hashes." – Jordan Arsenault Aug 08 '20 at 19:57
  • @JordanArseno - I know. It's an efficient data structure for this task, but at the end of the day it's still just a kind of a (very specific) database. – Vilx- Aug 08 '20 at 21:04
1

MD5 has its weaknesses (see Wikipedia), so there are some projects, which try to precompute Hashes. Wikipedia does also hint at some of these projects. One I know of (and respect) is ophrack. You can not tell the user their own password, but you might be able to tell them a password that works. But i think: Just mail thrm a new password in case they forgot.

Steven Sudit
  • 19,391
  • 1
  • 51
  • 53
dz.
  • 1,286
  • 12
  • 12
  • The fact that MD5 is broken (for specific but important uses of the function) has absolutely *nothing* to do with rainbow tables (which is what you hint at when mentioning precomputation of hashes). – Maarten Bodewes Sep 18 '18 at 21:42
1

In theory it is not possible to decrypt a hash value but you have some dirty techniques for getting the original plain text back.

  1. Bruteforcing: All computer security algorithm suffer bruteforcing. Based on this idea today's GPU employ the idea of parallel programming using which it can get back the plain text by massively bruteforcing it using any graphics processor. This tool hashcat does this job. Last time I checked the cuda version of it, I was able to bruteforce a 7 letter long character within six minutes.
  2. Internet search: Just copy and paste the hash on Google and see If you can find the corresponding plaintext there. This is not a solution when you are pentesting something but it is definitely worth a try. Some websites maintain the hash for almost all the words in the dictionary.
Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
vikkyhacks
  • 3,190
  • 9
  • 32
  • 47
0

MD5 is a cryptographic (one-way) hash function, so there is no direct way to decode it. The entire purpose of a cryptographic hash function is that you can't undo it.

One thing you can do is a brute-force strategy, where you guess what was hashed, then hash it with the same function and see if it matches. Unless the hashed data is very easy to guess, it could take a long time though.

Ajanyan Pradeep
  • 1,097
  • 1
  • 16
  • 26
-1

It is not yet possible to put in a hash of a password into an algorithm and get the password back in plain text because hashing is a one way thing. But what people have done is to generate hashes and store it in a big table so that when you enter a particular hash, it checks the table for the password that matches the hash and returns that password to you. An example of a site that does that is http://www.md5online.org/ . Modern password storage system counters this by using a salting algorithm such that when you enter the same password into a password box during registration different hashes are generated.

oziomajnr
  • 1,671
  • 1
  • 15
  • 39
-2

No, you can not decrypt/reverse the md5 as it is a one-way hash function till you can not found a extensive vulnerabilities in the MD5. Another way is there are some website has a large amount of set of password database, so you can try online to decode your MD5 or SHA1 hash string. I tried a website like http://www.mycodemyway.com/encrypt-and-decrypt/md5 and its working fine for me but this totally depends on your hash if that hash is stored in that database then you can get the actual string.

Rafi Ahmad
  • 55
  • 2
  • 7