With the first kind, you don't have much control over the collision blocks, and the prefixes and suffixes have to be the same. This can still be useful - file formats can be carefully rigged so that the differences in the collision blocks are noticed somehow (e.g. misaligning length fields, changing testable field values, introducing different code). With MD5, these collisions take just seconds to compute; with SHA-1, the one known example (Shattered) took 2^63 hash evaluations to compute.
With the second kind, you can do a lot more evil, since you can pick two completely arbitrary prefixes. This was abused (for example) to create a rogue CA certificate from an ordinary signed website cert. With MD5, this takes several hours with a good GPU and CPU; with SHA-1, it was previously thought to take around 2^77 evaluations - more than 16,000 times harder than the first type of attack.
This paper describes a method that would take only 2^69 evaluations for the second kind of attack on SHA-1, only 64x harder than the first type (in the worst case). This would be feasible for a big institution like Google or a government.
All of which reminds us that, yet again, SHA-1 deserves to be laid to rest.
Every time another article like this comes out I experience two emotions. First, a bit of smugness mixed with a lot of relief that I won that argument. Second, a bit of shock when people say "it's time to stop using SHA-1" as if that hasn't been the recommendation for 10 years.
It's dead, dead, dead. Now is not the time to have discussions about upgrading. Now is the time to start throwing people under the buss for dragging their feet on upgrades.
I recently asked a question on the pip issue tracker about whether it would make sense for pip to start accepting sha-1 git refspecs when running in --require-hashes mode, on the grounds that there's more upside to encouraging use of --require-hashes than there is downside risk of sha-1 collision attacks. This surely doesn't help that argument, but I'm not sure if it hurts it either.
Now it's reduced to shambles.
It's time to stop using SHA1. (HMAC-SHA1 is still okay.)
If you do know the secret key, collisions are easy, but probably pointless since you can already forge HMAC signatures for anything you want.
Still, even if there’s no way to break HMAC-SHA1 (or even HMAC-MD5) faster than the birthday attack, you should still prefer to pick a better hash algorithm for safety.
In this specific case, it's unclear whether the bug has direct security implications. The broken SHA-1 is used on some user-controlled data that gets XORed onto the server's decryption of a user-specified payload before being passed into an RC4 key schedule. It's certainly plausible that this might produce a server-assisted privacy compromise of other users' sessions.