The biggest problem with the scheme described is what you point out: encryption is not authentication. They are designed to provide two entirely different guarantees (confidentiality vs. integrity).

To provide a more concrete attack scenerio: if they used CBC encryption and stored the IV with the encrypted value (both very common practices with block cipher crypto), it would be trivial to spoof any user id by flipping IV bits.

On a more general note, the main problem appears to be basic lack of cryptographic knowledge. These "experienced developers" need to buy a crypto book and read it. Talented mathematicians have already solved their "problems" with academic rigor (in this scenario, using HMAC).

Flipping bits in CBC ciphertexts works just fine without the IV.

Right... I was assuming in this case that the message size would be < 1 block considering it's just a database id. In that case you'd have to modify the IV to flip id bits.

It's definitely way too easy to get crypto wrong especially if you don't have the basic cryptographic knowledge as you note. I think it is much better for developers to just try and use existing proven solutions and not try to make their own crypto solutions. I've worked on one project where it was possible to use the sessions that came with the web server (tomcat) which were implemented securely. however, instead we decided to do extra work to roll our own sessions which were implemented incorrectly using the database rand() function.

Good point. I may have even thought of that all those years ago, but I can't remember that far back. I eventually was just appalled that something so basic (and basically flawed) would be so sacrosanct and beyond discussion. Even after demonstrating - "look, if I have this key, I can identify as a different user" - I was essentially dismissed as a crank. At some point you get a label, and regardless of the validity of what you say, you're ignored, and that's a lesson I learned the hard way.

IIRC, doing any sort of validation on the PHP side was deemed to be too computationally expensive (you know, cause it's PHP) but somehow calling a webservice over a network that then connected to a database across a network as well was somehow 'performant'. An HMAC approach on the PHP side could have been done just fine, but I think it would have left the Java guys with less control over the process (which brings up again that this was less technical and more political).