Also, the original sin: framing it as "security" vs. "convenience". It's not. The other end of the spectrum is utility - as in, maximally secure computing device is an inert rock. More security means less utility - reduced functionality, constrained capability, reasonable use cases no longer possible. It means manual process where previously automation or batching was possible. It means more electricity, more compute, more money spent.
It means more user time and therefore more human lives wasted.
This ultimate non-renewable resource is what we're trading off when we accept even more security. This trade-off needs to be respected much more than it is.
That’s not what’s happening. Here you have security used as an excuse for vendor lock ins. Just like AI is used as an excuse for layoffs. But you shouldn’t confuse actual security with BS like this.
And it means more middlemen mediating people's access to their own tools.
I remember working at a major company where important systems had an admin password of "<company name>123". That was stupid. I asked to change it but the answer was no because too many people would have to be told the new password.
That was too much in favour of convenience and I'm surprised they never got pwned in the worst way.
These days the balance has swung way too much in favour of security though. Even when it concerns assets that have no value.
So what happened? Someone from IT came and said: "Oh yeah that always happens, just give me a USB stick and I'll stick it in the server". Which he did, no virus checking etc. This is the problem with processes that are too strict. They leave out usecases (often under a misguided "80/20 pareto" rule) and then people will figure out their workaround in unpredictable ways which you have no control over.
And most of the big hacks now are because of the move to cloud SaaS, especially salesforce instances are constantly being hit. Simply applying RBAC rules would fix that and not even interfere with anyone's job because the idea of RBAC is making sure that everyone can do just what they need to do their job and nothing more. But nothing LESS either. And of course some monitoring. If a local callcenter agent suddenly starts accessing 10.000 accounts per day instead of 20 a day, then yeah really you should be on the ball.
What youre complaining about isn’t security. It’s security theatre. Which is bullshit
> What you get is people getting sick of all the stupid hurdles and working around it. Using shadow IT. I find myself doing that too.
Unfortunately it’s people like yourself who implement shadow IT that end up forcing security and infra teams to add those annoying bureaucratic hurdles to force people in line.
But you do raise a point that I’ve often argued: good security needs to make it easy for people to do the right thing.
Unfortunately that takes a lot of time, effort, and investment to get right.
> And most of the big hacks now are because of the move to cloud SaaS, especially salesforce instances are constantly being hit.
lol no. That’s not even the tip of the iceberg.
> Simply applying RBAC rules would fix that and not even interfere with anyone's job because the idea of RBAC is making sure that everyone can do just what they need to do their job and nothing more.
Salesforce already has RBAC.
Also RBAC doesn’t prevent you from being hacked. It just limits the blast radius of what is exposed when you do get hacked. It also makes it harder for those who “know enough to be dangerous” to do the wrong thing. Like the shadow IT shenanigans you’ve admitted to.
It's because I still need to do my job. And I am also in the security team in fact. But we can't even "burn ISO's" anymore on memory sticks to install stuff in our test lab. When I ask they just say "80/20 rule" which apparently means, they spend the 20% effort on 80% of the usecases and the other 20% can go F themselves. Because the project manager doesn't care, he just wants to tick some boxes in the easiest way possible. That's how you get shadow IT.
> Also RBAC doesn’t prevent you from being hacked. It just limits the blast radius of what is exposed when you do get hacked. It also makes it harder for those who “know enough to be dangerous” to do the wrong thing. Like the shadow IT shenanigans you’ve admitted to.
Exactly, all the mega hacks with the release of millions of customers' data wouldn't have happened if that was properly implemented. Salesforce does have it but companies don't implement it.
And if people go to shadow IT it means that RBAC is not properly implemented because they don't have enough rights to do their job.
For starters, your complaint about IT is representative of bad IT operations. NOT security as an industry, like you claim it is.
And your comments about RBAC are such a massive oversimplification that I wonder if you actually do work in security at all. Because no competent security professional would claim that RBAC is a silver bullet that solves all issues.
Literally no one in security thinks this.
Better: not in a single metric but rather as a complete measure of both preventing unauthorized access to a resource and also _enabling_ authorised access to that same resource.
They also have 2fa built in. No need for a separate app, entering codes whatever.
Even if you don't like to rely on big tech (google/apple), I don't either, there are many options now for full FOSS implementations like bitwarden and KeepassXC.
If you use a yubikey as a passkey then yes, that's not a great option also because most services don't allow you to enroll more than one passkey. But with bitwarden that doesn't matter.
How do you sync passkeys to someone else's phone to authorize them to act in your name?
This is the basic use case, very common in the physical world, that security industry refuses to accept exists.
Passwords have this capability by nature.
> because most services don't allow you to enroll more than one passkey
Which is dumb and part of what makes passkeys not just useless, but dangerously so. Same story with 2FA, and the many services that only allow you to have one registered authenticator app at the time.
> Well that's why they can sync between devices.
What Passkey implantation syncs between devices? I've only ever seen "cloud sync", e.g. syncing with someone else's computer. Can a user sync iPhone passkeys with her Boox E-ink tablet (Android)? Can either sync with a Debian desktop?Not sure if either works on iOS, I don't use that but they work on desktop and Android (you use KeepassDX there to read them).
Passkeys are not an improvement. The way they're being implemented entrenches middlemen into auth flows in a way that reduces users' security in a broader sense, while being just as susceptible to compromise as any other form of credential.