Long story short: with all the mainstream hash algorithms, if you know the length of a hashed message, you can take its hash and from it synthesize the hashes of messages with arbitrary suffixes. It's called a message extension attack.
A really common pattern in hand-rolled authentication schemes is to hash a message needing authentication with a secret key, and then send the message and the hash. If you know the secret key, you can verify the message. The secret key doesn't need to be sent at all.
If your scheme is vulnerable to message extension attacks, attackers can mint arbitrary messages with valid authentication by taking an already-authenticated message and extending it to cover a suffix that changes the meaning of the legitimate message. It's a game-over flaw.
Colin Percival noticed a related (but less serious) flaw in Amazon's AWS authentication scheme. At the time, people asked if he'd looked at Flickr's scheme. He had, but not very closely. Colin's flaw was in canonicalization of messages, which is a more obscure attack (by a little bit) than message extension, which is is described in the Wikipedia under "Cryptographic Hash Function". Colin didn't flag this flaw.
Which just shows to go you: crypto primitives are radioactive. You are not going to get them right. Use high-level interfaces like GPG or SSL or cryptlib, or design your app not to need crypto.
To be fair, I didn't notice message extension attacks because AWS used an HMAC -- not a hash function -- and thus wasn't vulnerable.
crypto primitives are radioactive. You are not going to get them right
It doesn't take an expert cryptographer to know that if you want a MAC you should use a MAC.
If you're using .split() to "parse" untrusted input, and not even validating it against a regex first, that's an epic fail in its own right.
You can read more about the amazon problem at Colin's blog.
It's probably not fair to trace a cryptosystem flaw back to a web app security team.
Flickr authentication spec lists ludicorp.com authors,