[ryandrake]

It certainly feels that way here in 2026. It seems like I'm spending so much time "verifying" and "authenticating" and clicking somewhere so that the service can send me a code in E-mail. And more and more services are getting super aggressive. Biometrics, 2FA, uploading government ID, uploading face scans... Good grief!

I can imagine being in info-sec is a rough life. When you get breached, they're blamed. So they spend all their time red-teaming and coming up with outlandish ways that their systems can be compromised, and equally outlandish hoops for users to jump through just to use their product. So the product gets all these hoops. And then an attacker gets even more creative, breaches you again, and now your product has horrible UX + you're still getting breached.

[xp84]

The way so-called ‘2fa’ has been implemented on 90% of the things I interact with as a consumer is an absolute farce. Control of a SIM is nearly 100% of the time sufficient to get absolute control of any account, and showing a $50 fake ID to a teenager at a cell phone store has probably a 99% success rate. Only sites for nerds, plus Google and Microsoft, support TOTP or passkeys. Everywhere else uses the sms BS for 2fa or often effectively 1fa if it can be used to reset the first factor. And these same idiots lecture you for your 100-character password for not containing “at least one of these SIX “special characters”, an upper, a lower, and a digit. `Password1!` is a suitable password to these systems.

[icedchai]

Don't forget about password reset policies. At one place with a dedicated "security theater" team, I have to change my password every 90 days, so I just add the year and month to a base password. Password!2602 it is!

[tracker1]

On the flip side... I can't tell you how many times I've had to explain how public/private key crypto works do developers and IT security staff working in government projects. And this is just for one-way trust of JWTs for SSO integrations.

I mean, I don't mind if the same dev public-keys are used nearly everywhere in internal dev and testing environments... but JFC, don't deploy them to client infrastructure for our apps.

FWIW, aside... for about the last decade, I generally separate auth from the application I'm working with, relying on a limited set of established roles and RSA signed JWTs, allowing for the configuration of one or more issuers. This allows for a "devauth" that you can run locally for a whoever you want usage. While more easily integrating into other SSO systems and bridges with other auth services/systems in differing production environments. Even with firm SSO/Ouath, etc services, it's still the gist of configuration.