1

Is it possible to use an Application Specific Integrated Circuit (ASIC) to brute force MD5 hashes and thus reverse them down to their original form? I know there could be multiple collisions, but leaving that aside, would it be possible? The idea interests me because I happen to have ASIC Miner Block Erupters which are ASIC's used to generate the SHA-256 hash, but why not MD5? Thanks in advance.

Spencer D
  • 3,376
  • 2
  • 27
  • 43

2 Answers2

2

This is a very old question, but while working with a client and working to convince them that they couldn't use MD5 to hash passwords and needed to upgrade to something more secure, this post came up in the discussion.

While the accepted answer is technically correct, one doesn't have to calculate all possible md5 hashes to break a password, one only has rotate strings and positions in a methodical fashion to land on actual passwords. If we assume 8 characters in length and the common rule of uppercase, lowercase, and digits at minimum, that's only 218 trillion combinations.

Within the narrow confines of the answer, yes, it is completely impractical to brute force md5 collisions, but it is absolutely feasible to throw random smaller data sets at MD5 records and see what matches you get. Put simply, to calculate every possible MD5 for a set of passwords 5 characters in length containing letters, numbers and special characters might take two hours at 1 Mh/s.

I did that exact thing using a MacBook and some hastily written code for the aforementioned client. Within the span of the 45 minutes it took to explain the problem, and for them to point to this answer as a reason that they didn't need to bother, I had already gotten almost a thousand of the horrifyingly insecure passwords stored in their database.

Long story short, I just don't want people reading this answer and thinking that passwords hashed using MD5 are impossible to crack.

user1119648
  • 531
  • 1
  • 5
  • 16
  • That's a fair concern. Most compromise scenarios involve obtaining a dump of a user account database, which may contain usernames & password hashes, among other info. Best practices say passwords hashes should include a unique salt for each user, to mitigate against rainbow tables. The struggle with MD5 is that it is so fast to compute. Even with a unique salt for each user, it is fast to test the one million most common passwords against a given digest. Algorithms like Argon2 should be preferred for password hashing. If that's not available, then PBKDF2 with >10,000 rounds should be used. – Spencer D Oct 02 '21 at 17:59
1

A brute force attack is futile as there are 2^128 MD5 hashes. If you could compute 10^18 (that's a billion times a billion) hashes per second it would still take billions of years to find a single collision (unless you are extraordinarily lucky). Terahashes per second is not nearly enough. 2^128 / 1 terahertz is in the order of 10^26 seconds, which is about 10^19 years.

MD5 is broken, but broken does not imply "feasible to brute force", only "feasible to attack in some manner (probably more sophisticated than brute force)".

  • However let's say you have a significant amount of money and you decide to invest in an ASIC chip specifically for generating MD5 and you have a console application to read the input from multiple chips and then send them the next possible option for the brute force? Following that logic you could be generating beyond terrahashes even up into the trillions of terrahashes per second. The bitcoin world has showed us this. Many ASIC companies are now producing terrahash/s machines. MD5 is less cpu-intensive which means it could, in theory, be generated faster than a sha256 on an asic. – Spencer D Dec 14 '13 at 16:55
  • @SpencerGrantDoak You apparently have no idea how inconceivably large 2^128 is. It's roughly 10^38. Tera-... (10^12) is peanuts against that, there's a gap of about 26 orders of magnitude. In other words, if you achieve a 10^12 Hz Md5 ASIC, you need 10^26 of those machines to brute force one hash per second. Let's say you get lucky, find hashes earlier, optimize the ASICs some more, etc. - and wind up needing only 10^21 machines. Can you fathom the number 10^21 and how impractically large it is? –  Dec 14 '13 at 16:59
  • Nobody said brute forcing once per second. But leave a well developed asic rig to run for a month and I don't see why this is so impossible. – Spencer D Dec 14 '13 at 17:21
  • 1
    @SpencerGrantDoak A second was an example because it's convenient for back of the envelope calculations and because at this order of magnitude, allowing 10 or 100 or even a million times more computing power (or equivalently, more time with fixed computers) doesn't change much. Do the math. How many machines, ballpark, do you need to get results in a month? (I can tell you without grasping any numbers that it will still far beyond any reasonable number.) –  Dec 14 '13 at 17:27
  • If you say so. I suppose it's a dream of the future and by the time it becomes feasible nobody will even be using MD5. – Spencer D Dec 14 '13 at 19:12
  • If brute-force is out of the equation, then what other way could one reverse an md5? The only other way I could think of would be to create a database that's constantly added to with common md5 hashes and the strings that produce them; however that seems rather unreasonable. – Spencer D Dec 14 '13 at 20:07
  • @SpencerGrantDoak That's just brute forcing with memoization, and hence equally out of reach. The art of finding attacks smarter than brute force is called cryptanalysis, and that's a broad and hard subject. There is some rather successful cryptanalysis of MD5 (though not for preimage attacks AFAIK), and of course in many specific cases you can do better than brute force by educated guessing (e.g. for password cracking, trying known/common passwords first). –  Dec 14 '13 at 20:18
  • I'll have a look over the subject of cryptanalysis, I have found many sites that use "Rainbow Tables", but, quite obviously, unless the rainbow table includes the salt in the key, salted hashes are still unreachable with this method. – Spencer D Dec 14 '13 at 20:22
  • @SpencerGrantDoak Those tables exist in the first place because they're a subset of the hash space that's feasible to compute and useful at breaking (for example) password hashes. You can calculate your own in little time. Salted hashes slow down "guided brute force" attacks by preventing memoization like you suggested earlier, but if you know a password hash and a salt, you can still attempt to break the hash, in the same manner the rainbow table was generated. –  Dec 14 '13 at 20:26
  • Hmm interesting enough. I'll look into it. – Spencer D Dec 14 '13 at 20:35
  • @SpencerD The current attacks on MD5 do not allow _reversing_ the hash, which would be a preimage attack (which MD5 is still secure from). What MD5 is vulnerable to is a collision attack where an attacker creates two arbitrary inputs that have the same hash. Collision attacks were supposed to take 2^64 attempts, but due to a weakness in MD5, they only take 2^18, if memory serves. – forest Jun 08 '18 at 10:18
  • This answer seems to be based strictly on finding a collision, but brute forcing md5 usually implies you are brute forcing a password. `AZ|az|09|~?` character set could be iterated upward and surely you'd crack passwords even up to 10 characters long in mere hours with, say, 110 TH/s ... `((26+26+10+14)^10)/110000000000000`. A password like this `A3z$?DL>5~` wouldn't stand a chance against an MD5 ASIC, should they exist one day at the level BTC ASICs are achieving... Am I missing something? – Albert Renshaw Sep 02 '20 at 09:08