I have written preciously that I have a mishonor to work on a product which is so ridden with WTFs that if I wrote a story about each one of them, they all would make a hefty book which would be totally possible to break someone's cranium with. I even suspect I know whose cranium it would break first.
Here's one gem I came across recently.
Imagine your software has to read in and process documents prepared by different companies. Also, there are rules by which all those documents are entered into the software by a trusted third party. The documents come enveloped, sealed, with a CD-R next to a printout of the same document. The thing is to make sure the documents cannot be seen by other companies until the time comes. And when the time comes, they are being entered into our system, and here the WTF begins.
Of course when you have data that sensitive, you should make sure the thing in the envelope and the CD-R was made by whoever claims it was made by. For paper documents, you make it with old good seals and signatures, on CD you would expect a verifiable cryptographic signature (say, with a certificate or whatnot). No. We can do better. We can do checksums!
The checksum is a MD5 (which has been proven to be a WTF in itself for quite a while now), but the funniest part is that only first 4 octets of that MD5 are ever taken into account. The reason? The checksum is printed on that document, in hex (8 characters), and the operator needs to type it into a form along with uploading the file with that document (and typing in the whole MD5s, dozens of them, can make brave men cry in despair). The software will proceed if that typed checksum matches the checksum embedded into the file and that embedded checksum is the same as the one calculated from the data payload on the fly.
The document file is a PDF which has the same content as the printed thing, and is actually the original which is printed out. Two extra blobs are attached to it, the one with machine-readable data payload, and the one with the checksum. The best thing about it is that while the data payload has a half-arse protection with a quarter of a message digest, the rest of the PDF is not. Also, there is no proof whatsoever that the envelope is really from the company that is written on it: anyone could swap it for another one, and it would sneak unsuspected while the checksums on paper and in the file match the real thing.
To add some extra pain, our client-side software that is used to make those PDFs, an atrocity written in C# for Silverlight, once in a blue moon does really weird things, like calculating a wrong checksum (which has been proven next to impossible to reproduce). This is unnoticed until the PDF upload failure due to a wrong checksum. The practical outcome is that the unlucky company doesn't get a chance to win a contract for a hefty sum, which makes its top people very, very sad.
Proper security and digital signatures? What? Never heard of those.