Edit: To be specific, I was thinking of a Pascal-style length-at-start arrangement. It's clear that if you put the length at the end you may be vulnerable to exactly the same attack!
Secret: secret Message: foo&bar Let's include the length and hash 'secretfoo&bar13'
What you actually hash is 'secretfoo&bar130x80...padding...0x20'. What the attacker sees as the 'known hash' includes this padding. When you perform an extension attack, the attack message would look like: secretfoo&bar130x80...padding...0x02&evil . At this point you're adding on the length and hashing it, so what you compare with is 'secretfoo&bar130x80...padding...0x02&evil93' ... but the attacker can precompute that hash just as easily as the one with just 'evil' appended.
You could argue that your hashes would be constructed a bit differently (eg make messages that appear to have internal padding illegal; still vulnerable, btw), but the point is - you're still tinkering with the same basic structure, and are likely to make more mistakes. You're better off switching to HMAC for this application.
Edit: Doh, SHA2-224 and SHA2-384 are truncated and aren't vulnerable
But I was specifically thinking of the following scheme:
Message: [length][key-value pairs]
Hash: MD5 (shared secret, message)
Assuming that the rule is: the length is at the start of the message, and only "length" bytes of the message are used after the hash check passes.
It seems that if you have found a hash collision, Merkle Damgard lets you find more collisions easily. But the exploit in the article doesn't require a hash collision. If you haven't found a hash collision, would the above scheme be vulnerable to length extension?
Deleted comment
Again, this works on MD4, MD5, SHA1, and all the SHA2's.
You shouldn't have deleted your comment. You're not expected to know this stuff. Very few people, relative to the whole industry, or even relative to the number of programmers who end up trying to build crypto, actually do know how a length extension attack works.