It does matter what hash function you use, though. MD5 and SHA-512 are both vulnerable to length extension, but there are other hash functions that are not, like SHA-512/256, SHA-3 or BLAKE.
The documentation for both Keccak and BLAKE2 recommend prefixing a fixed-length key to the message to do MAC, pretty much like in the vulnerable example, but with a better hash function.
> other hash functions that are not, like SHA-512/256
I think you meant SHA-224/384. Both SHA-512 and -256 are vulnerable to length extension because their internal state is dumped and resumable. With SHA-224/384, you only get a truncated state (from 256- and 512-bits respectively), which you can't pick up and resume.
I do mean the hash function "SHA-512/256", as defined in FIPS 180-4 [1]. It is basically a version of SHA-512 that truncates the final result to 256 bits (Like SHA-384). It is not vulnerable to length extension, because unlike SHA-256, the final hash does not contain enough state to continue hashing.
I wouldn't consider SHA-224 immune to length extension since it only truncates 32 bits, which is low enough to brute force.
Ahh, quite right. Sorry about that. And yeah, I agree on SHA-224; it's okay in certain circumstances (you're rarely going to be able to pull off 2^31 (average) requests), but it's almost definitely not the right choice.
The documentation for both Keccak and BLAKE2 recommend prefixing a fixed-length key to the message to do MAC, pretty much like in the vulnerable example, but with a better hash function.