Hoping to avert “collision” with disaster, Microsoft retires SHA1

After 2016, Microsoft will stop accepting the collision-prone crypto algorithm.

Microsoft is retiring two widely used cryptographic technologies that are growing increasingly vulnerable to attacks that seemed unlikely just a decade ago.

The company's software will stop recognizing the validity of digital certificates that use the SHA1 cryptographic algorithm after 2016, officials said on Tuesday. SHA1 is widely used to underpin secure socket layer (SSL) and transport layer security (TLS) certificates that authenticate websites and encrypt traffic passing between their servers and end users. SHA1-based certificates are also used to digitally verify that specific software applications are legitimate and not imposter programs or programs that have been tampered with to include hidden backdoors.

The move comes as hardware improvements and research breakthroughs have made SHA1 and several other cryptographic hashing algorithms more susceptible to so-called collision attacks. Collisions occur when two distinct plaintext "messages" produce an identical hash or "digest." The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

The state-sponsored Flame malware that targeted Iran pulled off the only known in-the-wild collision attack earlier this decade. Using a never-before seen technique to subvert the MD5 algorithm, Flame-infected computers were able to pose as official servers belonging to Microsoft. By forging Microsoft's digital signatures, the infected machines were able to trick uninfected computers into installing highly malicious software they otherwise would have refused. Microsoft has since decommissioned MD5 in its update system. Tuesday's advisory indicates that the company is aiming to learn from that past incident by retiring SHA1 before it falls to the same type of attack.

"Since 2005 there have been known collision attacks (where multiple inputs can produce the same output), meaning that SHA-1 no longer meets the security standards for a producing a cryptographically secure message digest," Tuesday's advisory explained. "For attacks against hashing algorithms, we have seen a pattern of attacks leading up to major real-world impacts."

(Almost) unimaginable consequences

Back-of-the-envelope math published last year showed that SHA1 could fall to viable collision attacks by 2018. Those calculations didn't take into account the use of video cards or newer mathematical-based techniques to carry out the attacks. Depending on how well these and other alternative methods work, it's possible that the attacks could be viable sooner. Given the ubiquity of SHA1 now, its demise would spell almost unimaginable consequences in today's landscape. While collision attacks wouldn't allow attackers to decode encrypted traffic that's intercepted, it would make it much easier for them to create fraudulent certificates that could be used to validate malicious websites and software.

Microsoft officials went on to recommend that customers stop using SHA1 now and begin using certificates based on SHA2, which is much more resistant to collision attacks.

Decommissioning RC4

Also on Tuesday, Microsoft recommended that customers dump the RC4 cryptographic cipher on their websites and in their apps and replace it with something compatible with TLS version 1.2.

"Microsoft strongly encourages customers to evaluate, test, and implement the options for disabling RC4 below to increase the security of clients, servers, and applications," company representatives wrote in a separate advisory. "Microsoft recommends enabling TLS 1.2 and AES-GCM. Clients and servers running on Windows with custom SSL/TLS implementations, such as Mozilla Firefox and Google Chrome, will not be affected by changes to SChannel."

Promoted Comments

A few years back I was updating a medical system which ran using libraries compiled before I was born, and we didn't have the code for them. We advised our client to do fully replace the software and some of the hardware, but they weren't willing to pay. Many companies just aren't willing to spend more than 6 figures on something which (seemingly) works.Since the software isn't critical for patient care, and I was switching companies, I didn't continue pushing it, but I can imagine this behavior happening where it can't be allowed to.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

The strength of a hash isn't really about randomness of collisions. It's about the difficulty in finding a collision on purpose. First, the collisions aren't truly random, as they are entirely deterministic. A better term would be that they are pseudo-random. Second, one could imagine a hash function that results in a similarly-random-appearing distribution of hashes, but where some weakness in the function makes it relatively easy to collide on purpose. This was, in fact, what happened with MD5. "Someone" found a weakness that allowed a purposeful collision using much less processing power than if they simply brute-forced a collision.

I just killed RC4 ciphers and support for SSL 2 & 3 on my personal server plus got perfect forward secrecy enabled, but since I'm the only user right now from IE 9 at work to Safari on Mac/iOS for home/mobile it was pretty easy. I'm debating killing TLS 1.0 and only leaving TLS 1.1 and 1.2 but haven't yet. Also debating removing all the 128-bit ciphers and only allowing 256.

Now at work I have to move much slower. Our users are gov't agencies, not exactly swimming in upgrade money at the moment, so I'll have to proceed with caution and be ready to back out.

If you want to test a server's SSL implementation try running it through SSL Labs checker. Nice tool:https://www.ssllabs.com

Since people that remain using IE6 do so solely for compatibility with... something, I'm rather surprised that MS doesn't have a Trident engine plugin for more modern versions of IE that can properly render that (old) content.

A few years back I was updating a medical system which ran using libraries compiled before I was born, and we didn't have the code for them. We advised our client to do fully replace the software and some of the hardware, but they weren't willing to pay. Many companies just aren't willing to spend more than 6 figures on something which (seemingly) works.Since the software isn't critical for patient care, and I was switching companies, I didn't continue pushing it, but I can imagine this behavior happening where it can't be allowed to.

Since people that remain using IE6 do so solely for compatibility with... something, I'm rather surprised that MS doesn't have a Trident engine plugin for more modern versions of IE that can properly render that (old) content.

Generally speaking the issue with needing old IE version compatibility is not a matter of rendering (which Compatibility Mode handles quite well for the most part), but of plugins. Usually from companies that no longer exist or are no longer supporting upgrading from such old products. These plugins are often mission critical, so the travesty that is XP+IE6 lives on.

For home users I suspect the one and only issue is cost vs benefit. They don't believe they need a new PC (and they probably don't really) enough to spend $500 on a new machine.

Better hope they can enforce a move away from SHA1 on the XP & IE6 zombies that continue to roam the wastelands of the inet

Or maybe we could let them be totally incompatible with the new security protocols in websites so they are forced to upgrade.

Definitely, I'm all for it. Chances are the business behind it won't back that though, the risk of losing customers is too high.

IMHO MS and others need to roll out security updates like this to the masses, question is how? Windows Update is ok, Google's auto update for Chrome is neat, but it's a tough problem to solve, you still end up with a nasty tail of old versions.

Whatever default you set in whatever product you ship it's going to be the first target of black hats because a huge percentage go with the default. People want to be able to opt-out etc.

Since people that remain using IE6 do so solely for compatibility with... something, I'm rather surprised that MS doesn't have a Trident engine plugin for more modern versions of IE that can properly render that (old) content.

IE6 usage in the wild is mostly not Joe Swivel Chair-Spread trapped in a tarpit of crappy legacy software. The overwhelming majority of it's continued usage is due to the popularity of several versions of WarezDozeXP in China that had automatic updates disabled as protection against things like WGA screwing up the systems.

Better hope they can enforce a move away from SHA1 on the XP & IE6 zombies that continue to roam the wastelands of the inet

Or maybe we could let them be totally incompatible with the new security protocols in websites so they are forced to upgrade.

Definitely, I'm all for it. Chances are the business behind it won't back that though, the risk of losing customers is too high.

IMHO MS and others need to roll out security updates like this to the masses, question is how? Windows Update is ok, Google's auto update for Chrome is neat, but it's a tough problem to solve, you still end up with a nasty tail of old versions.

Whatever default you set in whatever product you ship it's going to be the first target of black hats because a huge percentage go with the default. People want to be able to opt-out etc.

Employ "Darwin" to elliminate. Reinstate XP updates sans WGA where the result is "malware" that isn't that malicious. Use the same technique as ransomware to encourage upgrades, but this time of OSes.

Start treating malware like bacteria, some good, some bad. We currently just try to kill all of them, but there isn't a real reason trojans, worms and viruses can't be put to some good. Other than explicitly running programs to do the same task is more efficient.

Better hope they can enforce a move away from SHA1 on the XP & IE6 zombies that continue to roam the wastelands of the inet

Or maybe we could let them be totally incompatible with the new security protocols in websites so they are forced to upgrade.

Definitely, I'm all for it. Chances are the business behind it won't back that though, the risk of losing customers is too high.

IMHO MS and others need to roll out security updates like this to the masses, question is how? Windows Update is ok, Google's auto update for Chrome is neat, but it's a tough problem to solve, you still end up with a nasty tail of old versions.

Whatever default you set in whatever product you ship it's going to be the first target of black hats because a huge percentage go with the default. People want to be able to opt-out etc.

How many true customers are using IE6 anymore? Not many. Most of those people are ones that you sold stuff to YEARS ago, have bought nothing since, and therefore their 'likes and dislikes' should not really be taken into account.

Since people that remain using IE6 do so solely for compatibility with... something, I'm rather surprised that MS doesn't have a Trident engine plugin for more modern versions of IE that can properly render that (old) content.

IE6 usage in the wild is mostly not Joe Swivel Chair-Spread trapped in a tarpit of crappy legacy software. The overwhelming majority of it's continued usage is due to the popularity of several versions of WarezDozeXP in China that had automatic updates disabled as protection against things like WGA screwing up the systems.

No. Just no. Microsoft has NEVER been able to cut down on 'pirated' versions of Windows. I personally have to run 'pirated' versions that were legally bought ones, because I like to do a clean install of my system to blow away the crapware.Microsoft doesn't provide an easy way to put back in the OEM stuff, so I am forced to use 'cracks' for Windows to get my legally bought software running.

No. Just no. Microsoft has NEVER been able to cut down on 'pirated' versions of Windows. I personally have to run 'pirated' versions that were legally bought ones, because I like to do a clean install of my system to blow away the crapware.Microsoft doesn't provide an easy way to put back in the OEM stuff, so I am forced to use 'cracks' for Windows to get my legally bought software running.

Hmm...You have to do something as a result of something you like to do?

Not that I'm judging...let's just say I much prefer a clean install of pure Windows over spending hours uninstalling OEM shovelware, and the last pre-built PC I had was a Compaq with a 233MHz processor.

I also have to say I learned a hell of a lot from the original IT guy where I work - when management said they wanted it done right but cheap, who knew which end of the dial that pointer needed to land on.

Personally, I think MS should stop trying to charge Grandma $150 for an OS - make the Home version dirt-cheap and restricted - no domain joining, no encryption, etc. Stick the corporate customers for the real money. You know, sort of like it is now, only without the high price tag on the Home version. Sure, you'll have some crackers and shady IT staff cutting corners, but pirates will always pirate.

I never thought I'd be agreeing with MS on security matters but TLS 1.2 is something that should have happened a long time ago.

Yes indeed. Firefox and Chrome have been very poor in TLS 1.2 support. TLS 1.2 has been available in IE for several versions now and development tools supporting it have been around for a while too. OpenSSL, dot net framework, java support it and the news isn't going to get better for TLS 1.0 as time goes on...

I never thought I'd be agreeing with MS on security matters but TLS 1.2 is something that should have happened a long time ago.

Yes indeed. Firefox and Chrome have been very poor in TLS 1.2 support. TLS 1.2 has been available in IE for several versions now and development tools supporting it have been around for a while too. OpenSSL, dot net framework, java support it and the news isn't going to get better for TLS 1.0 as time goes on...

The old Opera (before they became a Chrome clone) has supported it for a while too. If tiny little Opera can support it then what excuse do Mozilla and especially Google have.

I'd like to see the defaults of IE 8 through 10 changed to enable TLS 1.2 by default. I believe 1.1 and 1.2 weren't enabled by default due to a number of web servers failing to correctly handle TLS 1.2 requests where they didn't have a TLS 1.2 certificate to deliver (or didn't have TLS 1.2 enable, I'm unsure on the terminology). With IE 11 enabling this by default now I presume Microsoft is comfortable that it's been mostly resolved, thus there's no reason to keep those less secure defaults on older versions of the browser.

I don't think it'll happen because from a support perspective it's easier for them to have that divide, but still, it'd be nice and help drive TLS 1.2 adoption.

After what, 20 years(?) after the OCX debacle and South Korea still depending on the bloody things, Microsoft finally gained a clue about security? I had given up all hope when the failed to retire MD5.

Then again, that MD5 thing made them look so dumb perhaps they decided cooperating with the NSA was just too costly.

Since people that remain using IE6 do so solely for compatibility with... something, I'm rather surprised that MS doesn't have a Trident engine plugin for more modern versions of IE that can properly render that (old) content.

IE6 usage in the wild is mostly not Joe Swivel Chair-Spread trapped in a tarpit of crappy legacy software. The overwhelming majority of it's continued usage is due to the popularity of several versions of WarezDozeXP in China that had automatic updates disabled as protection against things like WGA screwing up the systems.

Not to forget the surprisingly large number or people in the west that can afford to upgrade but refuses to because "it works" and their brains melt at the thought of having to do anything differently. I know a number of such people and I dread the day I have to move them from Windows XP. I'm thinking about throwing in Slackware on their machines, then suddenly dissapear.

Since people that remain using IE6 do so solely for compatibility with... something, I'm rather surprised that MS doesn't have a Trident engine plugin for more modern versions of IE that can properly render that (old) content.

IE6 usage in the wild is mostly not Joe Swivel Chair-Spread trapped in a tarpit of crappy legacy software. The overwhelming majority of it's continued usage is due to the popularity of several versions of WarezDozeXP in China that had automatic updates disabled as protection against things like WGA screwing up the systems.

Not to forget the surprisingly large number or people in the west that can afford to upgrade but refuses to because "it works" and their brains melt at the thought of having to do anything differently. I know a number of such people and I dread the day I have to move them from Windows XP. I'm thinking about throwing in Slackware on their machines, then suddenly dissapear.

It's wrong education. People are often taught how to use the computers, make things work, not about security. Even though I studied IT at the university at some classes we were advised to NOT update some software because it may break stuff. No wonder with such a approach people get owned so easily. Luckily I was also taugh by wise people so I developed the "paranoia" aboutsecurity. We wrote first web app and then we were shown how to break into it etc. Funny times.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Thanks for chrystalizing so clearly such a complex concept. Nicely done.

It can be a challenge to add all the important provisos and details when writing on deadline. I'll be sure to add this point the next time I cover the topic of hash collisions.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Thanks for chrystalizing so clearly such a complex concept. Nicely done.

It can be a challenge to add all the important provisos and details when writing on deadline. I'll be sure to add this point the next time I cover the topic of hash collisions.

Wow, you don't have to be a jerk about it, sorry. Just wanted to point out an important distinction about hashes that gets often overlooked. Next time I won't say anything, and leave the high and mighty author alone.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Thanks for chrystalizing so clearly such a complex concept. Nicely done.

It can be a challenge to add all the important provisos and details when writing on deadline. I'll be sure to add this point the next time I cover the topic of hash collisions.

Wow, you don't have to be a jerk about it, sorry. Just wanted to point out an important distinction about hashes that gets often overlooked. Next time I won't say anything, and leave the high and mighty author alone.

How was I being a jerk? I was acknowledging you made a good point, thanking you, and explaining why it's sometimes hard for me to do as good a job as you did. On top of that, I promoted your comment so other readers can also benefit from it.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Thanks for chrystalizing so clearly such a complex concept. Nicely done.

It can be a challenge to add all the important provisos and details when writing on deadline. I'll be sure to add this point the next time I cover the topic of hash collisions.

Wow, you don't have to be a jerk about it, sorry. Just wanted to point out an important distinction about hashes that gets often overlooked. Next time I won't say anything, and leave the high and mighty author alone.

Wow, you thought that was sarcasm? I read it as agreement and praise for your comment.

I've seen some strongly worded comments from Ars authors, but I don't ever remember seeing sarcasm other than maybe in a humorous remark.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Thanks for chrystalizing so clearly such a complex concept. Nicely done.

It can be a challenge to add all the important provisos and details when writing on deadline. I'll be sure to add this point the next time I cover the topic of hash collisions.

Wow, you don't have to be a jerk about it, sorry. Just wanted to point out an important distinction about hashes that gets often overlooked. Next time I won't say anything, and leave the high and mighty author alone.

Wow, you thought that was sarcasm? I read it as agreement and praise for your comment.

I've seen some strongly worded comments from Ars authors, but I don't ever remember seeing sarcasm other than maybe in a humorous remark.

Thanks for your comment, DNick.

And for the record, I think sarcasm is a counter-productive form of communication. For one thing, the bitterness and ridicule that fuel sarcasm are usually motivated out of desire to attack others rather than exchange information or a point of view. And for another, sarcasm often arouses anger, bitterness, or defensiveness in those on the receiving end. I strive never to use sarcasm in articles, comments, tweets, or any personal communications, although in the heat of the moment I sometimes fall short of that goal.

What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Partially wrong. The randomness is fixed to a uniform distribution of 1/2^numOfBits, but what makes a good hash function is adherence to that random distribution (to avoid or minimize collisions) AND being non-reversible (the one way trapdoor function).

What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Partially wrong. The randomness is fixed to a uniform distribution of 1/2^numOfBits, but what makes a good hash function is adherence to that random distribution (to avoid or minimize collisions) AND being non-reversible (the one way trapdoor function).

"adherence to that random distribution" is a bit ambiguous. Many hashes adhere very well to random distribution when fed normal data, but those hashes may be influenced by someone who purposefully feeds in data that causes a bias.

Cryptographically secure hashes are resilient to induced biases. An example is that MD5 is still a great and highly recommend hash for validating that your data didn't get corrupted from data rot or transmission errors, but it is not resilient against purposeful attempts to create a collision.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

Thanks for chrystalizing so clearly such a complex concept. Nicely done.

It can be a challenge to add all the important provisos and details when writing on deadline. I'll be sure to add this point the next time I cover the topic of hash collisions.

Wow, you don't have to be a jerk about it, sorry. Just wanted to point out an important distinction about hashes that gets often overlooked. Next time I won't say anything, and leave the high and mighty author alone.

Wow, you thought that was sarcasm? I read it as agreement and praise for your comment.

I've seen some strongly worded comments from Ars authors, but I don't ever remember seeing sarcasm other than maybe in a humorous remark.

FWIW, it sounded like sarcasm to me as well. The phraseology/tone (excessive?) could well be (was) taken for sarcasm if unfamiliar with the writer.

FWIW, it sounded like sarcasm to me as well. The phraseology/tone (excessive?) could well be (was) taken for sarcasm if unfamiliar with the writer.

Miss-communication by cultural differences?

Quite possibly. And thanks for your feedback, pxkanad. Is there something I can do in future comments to avoid the miscommunication?

As the author, the original commenter may have been more vulnerable and thus quick to assume sarcasm. It was the slightly overblown almost pedantic phraseology that had me scratching my head as to why you were being sarcastic to a really very valuable and enlightening point about hash functions.

I know you were attempting praise but perhaps short and sweet along the lines of "Really good point that I will include in future. Thanks for pointing that out!" would have sounded more genuine to the commenter, if kind of bare or possibly dismissive to yourself.

Dan, thank you for your "right on" comments on sarcasm in communication. Though sarcasm can be amusing very briefly to a few it is usually very painful to the target, damaging to the discourse, and makes the author look very small.

(In some venues, I do think sarcasm is well served and deserved... Politics and the discussion of lawyers comes to mind.)

A few years back I was updating a medical system which ran using libraries compiled before I was born, and we didn't have the code for them. We advised our client to do fully replace the software and some of the hardware, but they weren't willing to pay. Many companies just aren't willing to spend more than 6 figures on something which (seemingly) works.

One of the advantages of free and/or open-source software is that the upgraded software itself doesn't cost money, reducing the likelihood of users unwisely using older software.

A few years back I was updating a medical system which ran using libraries compiled before I was born, and we didn't have the code for them. We advised our client to do fully replace the software and some of the hardware, but they weren't willing to pay. Many companies just aren't willing to spend more than 6 figures on something which (seemingly) works.

One of the advantages of free and/or open-source software is that the upgraded software itself doesn't cost money, reducing the likelihood of users unwisely using older software.

And one of the disadvantage of free and/or open-source software is that the developers might have no incentive to update their software.

The security of an algorithm rests on it producing unique hashes for each plaintext string or file. The growing ease of producing collisions makes it possible for attackers to create digital forgeries that completely undermine the security of systems that rely on the weak algorithms.

You leave an incomplete/poor definition of hash functions. By definition, a hash takes an infinite number of different inputs and produces a finite number of results (128 bit hash, there's only 2^128 different results). ALL hash functions produce collisions. Its inevitable. What makes a strong hash is the randomness of these collisions, not its ability to avoid them (assuming you've chosen a large enough hash of course, an 8 bit hash is obviously too small).

The strength of a hash isn't really about randomness of collisions. It's about the difficulty in finding a collision on purpose. First, the collisions aren't truly random, as they are entirely deterministic. A better term would be that they are pseudo-random. Second, one could imagine a hash function that results in a similarly-random-appearing distribution of hashes, but where some weakness in the function makes it relatively easy to collide on purpose. This was, in fact, what happened with MD5. "Someone" found a weakness that allowed a purposeful collision using much less processing power than if they simply brute-forced a collision.