Possibly OT, but a security story/rant all the same. I worked on a project where web session information was managed by a java/php dance. PHP serving the front end would ask a Java web service for a session token (or pass a session token in to validate it). The Java web service would generate a new session token by add a row to a database and returning a string of characters. The string of characters was the auto increment ID of the database row, encrypted with a key. When the Java web service got the token again, it would decrypt it to see if it matched a valid row ID in the database. The token was sent down in a web cookie.

I was then asked to also use this same 'session management' approach on something with far more sensitive financial information (the original use case was arguably already something sensitive, although not directly tied to financial records). I refused, and explained why. I was told I didn't understand security. I suggested tying the row to a random ID and using that. I was told that 'random generators aren't really random - you need to understand how computers and processors work to know that'. It took me 5 months from when I first brought this up as a security concern to someone above me actually understanding the problem - not necessarily agreeing with my conclusion that it was unsafe, but at least understanding why it could be unsafe. BTW, none of my nominal colleagues took it - or me - seriously - cause after all, I only did PHP - it doesn't even have threads (that was an actual quote from someone).

The problem was if someone managed to decrypt the cookie value, they'd immediately see it was a number like 109826374. Trying again a few minutes later, they'd see 109826379, etc. Yes, potentially hard to decrypt in the first place (or to know that it was encrypted), but if done, devastatingly easy to assume another identity.

I was continually told I didn't understand web security, or computers, or programming, because I was new to the company, and developers far more senior than me had developed this (at this point I'd been doing web development for almost 8 years, and had already made my fair share of stupid/dumb security mistakes, so I recognized this one instantly).

Finally someone 'got' it when I pointed out that dozens of people had come and gone, had access to the code, but more importantly, had had access to the encryption key. It hadn't been changed. Ever. I asked how they could ensure that people weren't already using that key to decrypt and take over accounts - there'd be no way they could actually identify if that was even happening. I think the immediate answer was to plan to rotate the encryption key on a regular basis, but I left soon after that (for more reasons than just this, but this was illustrative of how I was interacting with the place). Having values in a cookie that are tied to directly manipulatable database values simply isn't a good idea, even if the cookie is encrypted, and you certainly wouldn't want financial records stored with this as the primary (only?) means of security.

Was some of the failure my fault? Possibly. I may have come across as arrogant, or 'know it all', or whatever. I'd sent detailed tech emails to people outlining the issue. I'd had friendly lunch conversations. I'd demonstrated how it was possible. Nothing worked. And that was frustrating, and led me to coin my own phrase - "It doesn't matter what you say, it matters how you're seen when you say it".