What was being encrypted was a sequential DB ID that identified your user ID in the system. Decrypting the data (with the key that multiple people had access t

What was being encrypted was a sequential DB ID that identified your user ID in the system. Decrypting the data (with the key that multiple people had access to and there was no way of telling who'd taken it) would allow you to change your ID and re-encrypt and become someone else. (also, AFAICT, the same key was used for some internal data encryption too - same key used in multiple areas across different teams) This was initially just a marketing site, but I was being told to use the same system for authentication around a financial service, and I objected. I suggested the ID be random, then mapped to something else. I had multiple 'senior' developers try to explain why "random isn't really random" and had a lot of timing attacks associated with it. I kept pushing back that timing attacks weren't as big a problem as "someone having the key can impersonate anyone, and we can't prove that people haven't taken the key out of the company". I "only" had 9 years experience at this point, but was the 'new guy' in the company, having only been there a few months, and apparently hadn't "paid my dues" in their ecosystem for long enough to be taken seriously. It took weeks of me objecting before we had a big meeting, and their architecture was mapped out on a board, and defended. I then asked "how can you prove the key hasn't left the building with previous people?" Then my manager sort of "got it" and realized this was all kinda ... not something we should rely on for guarding financial info. Maddening that it took weeks of "deliberation" on this issue when it was patently insecure. I've not ever whiteboarded it out to anyone with more than a few years of experience who didn't stop me partway through to tell me that it was insecure. Dejected through all of this, I asked to be put on another project, but I was seen as a troublemaker at that point, then left.