Hacker News Reader

Security is also increasingly being used as a pretext for usurpation of end-user control over their own devices, which the situation in this very article seems to be a case of.

The industry, and society at large, are today overrun with fiduciaries who've convinced themselves that they are the principals.

hard not to believe them given the regulatory degradation. The orange menance also has a hug ego cause shit just keeps sliding his way.

Without regulations, billion dollar, multi continent countries can do as they want because their owners, citizens, etc arn't considered targets even when they make these decisions in concert if not in colusion, if not in conspiracy.

Regulations are principally a vehicle for these very sort of intrusive behaviors, given that their main effects are to create barriers to entry that entrench established business models and block competition, create a nexus of effectively legalized collusion between entrenched oligopolists in a given market, via influencing regulation, and replace general common-law liability with rules that can be manipulated by industry players. This pattern is found throughout the regulatory landscape.

There is a simple and highly accurate heuristic to tell if a security measure is reasonable:

Is it an open standard that anyone can permissionlessly implement?

When the answer is yes, there is a high probability that it's something reasonable, e.g. TOTP.

When the answer is no, what you will find behind the curtain is either a fool or a crook.

This heuristic is not covering the dimensions of interest here, because it fails to address the key security questions (that the industry usually wants people to not even think about):

Who is doing the securing, whose interests are being secured, and against who/what?

Security isn't an unqualified good thing to have. It's just an instrument of control. Who wields it and how are the paramount questions. You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner. In fact, that describes many, if not most, security measures introduced in computing over the past 20 years, especially on the web and mobile devices.

Right, and that leads us back to the more-generalized (but very classic) cui bono? Who gets the benefits?

In Apple's case, I don't know. I'm making macOS software, and the number of roadblocks I keep running into in the name of security is past merely annoying, it's costing real time and money to deal with it. Unfortunately that's where the users are so we have to spend the resources on it so it's an Apple tax on doing things on their platform. We have to spend more money on Apple development, so that ecosystem benefits? idk.

Yeah we were trying to develop an internal corporate MacOS desktop app and the amount of shit I had to go through just to get it to the point where someone who isn't a developer was able to run it was absolutely insane. In the end a lot of this is probably even counterproductive as people get used to these sort of things coming with instructions to disable all security and paste these sudo commands into a terminal to get it running...

It has been a known thing in security for what has to be decades now that taking a security/usability trade off in favor of "security" is the fast way to train users to mash the "allow all" button from muscle memory, thereby severely impairing security.

The premise of the scary banner has to be that the first time the user has ever seen it is when there is actually something wrong.

This is, of course, fully incompatible with the corporate incentive to present the scary banner whenever an honest third party hasn't paid them the danegeld or satisfied a bureaucratic process documented by Franz Kafka. If the thing you care about is actually security.

> You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner.

Except that you can't, because those systems require the device to come with secret keys, so an interoperable third party implementation would require keys, which requires permission, which is the exact thing "permissionless" is intended to evict.

Don't forget "Remember for 30 days" checkboxes that don't do anything.

I'm begging, please let me use password "asdfasdf" on throwaway accounts. I accept full responsibility for the fallout.

Seriously, many web admins need to hear this message: "Chill. Your site is not that important."

It’s always interesting to see how fast someone takes a proposal and takes it to some ridiculous extreme.

Websites don’t know your account is a throwaway one, and making an exception for those accounts doesn’t make sense anyway.

Saying “ I accept full responsibility for the fallout” obviously doesn’t work on a large scale and here exceptions don’t make sense either.

Just use a password manager that generates and fills your passwords, and never worry about your passwords for those sites. Don’t tell web admins to drop basic security measures because you don’t know how to manage passwords.

Your site is non trivial.

I'll repeat what GP wrote:

> Seriously, many web admins need to hear this message: "Chill. Your site is not that important."

No site is important until it is, but by then it's too late to overhaul your security architecture.

No, the site doesn't become important if it wasn't from the start. This is not conditioned on individual use cases. Government sites, your bank, your healthcare provider - they have the important sites. Your e-mail provider is important too, because by accident of Internet history, your e-mail is your backup key to everything in your digital life.

Beyond those, nothing is that important. Your random e-commerce site or discussion board are not that important. Neither is your ISP or the service where you fix your appliances (or phones). And especially not the random fly-by-night startups that want you to register before you test their "game changing" SaaS.

The sad irony is, the smaller and less important the site, the more stringent security measures they tend to deploy, because security theater is trendy nowadays. 2FA is so 2025, if you're not demanding passkeys, you're a dinosaur.

(A good heuristic to use: if your site has harder security than your government's core services, especially when it comes to recovering access, it's worth asking whether there's any actually sensible reason for it.)

> I accept full responsibility for the fallout.

But you can't - when it includes damage to the provider e.g. brand tarnishing.

A lot of user-access "security" is for the benefit of the provider, not the user.

Sometimes companies assume my password has been leaked and keep making me change it over and over again. Eventually, I end up forgetting my own password. It’s really frustrating.

You have a throwaway account?

Can't have that! We wouldn't have any data to sell!

We need ID, email verification address, phone number, and a selfie of yourself holding a handwritten sign saying, "I love <useless company #7983>" now.

And you have to do a captcha at every step. Click on every crosswalk, sucker.

All this boils down to governments wanting security from their citizens and corporations wanting security from their customers. It's not going to stop, ever.

Taking this attitude, it's guaranteed.

You forgot your $3 payout from the class action lawsuit when the company STILL gets hacked and the exec bonus pool increases because the settlement wasn't "that" bad.

$3 payout? You're being generous, last time there was a major breach, I believe Equifax gifted the victims a year of "free subscription" for their service.

Accountability is nonexistent in our industry.

The CRAs compete for the opportunity to offer "a year free credit protection" (that a breached company pays for), because to get it, you usually have to provide a credit card and subscribe to the highest tier. You get your free year and then they turn you into a paying member unless you remember to cancel.

Exactly. At work I now have to MFA and type a random code every time I want to book a desk. It kills the session after 30 minutes. It's ridiculous. If an attacker ever got hold of it, they could... book a desk at that shitty office for me. Whoopty doo what horror.

The same with logging my hours in a different system. I only use those systems for those things, nothing else.

Security is important for things that actually hold value. Like when I connect to my admin account. Or even when I connect to our intranet. But they enforce the highest level even for stupid stuff.

One insider threat actor might book a previously unbugged desk, bug it with multi-antenna keystroke logger (making and breaking resistive connections across parasitic capacitance nodes, changes the direction dependent EM scattering function). One can correlate acoustic key press detection with changes in scattering, unsupervised.

Fixed desks are way more secure than promiscuous desk multiplexing.

An insider threat actor can just do that without booking the desk. They just go in on a quiet day and sit down, nobody checks whether a desk is booked unless they themselves need to sit there.

I really think the IT security industry ought to be ashamed of itself.

See Pournelle's Iron Law of Bureaucracy.

> 2FA on every trivial site

But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api auth problems and atrocious out of date dependencies, err I mean...

> But it helps against account sharing

This is actually a feature, very common in real world, that security maximalists keep insisting is a bug.

My wife's insurance provider requires SMS 2FA, which is incredibly annoying for this reason - there's no way for me to submit my massage (or w/e) benefits even though my wife hates dealing with insurance admin and I have the login info and am authorized to do so - I have to wait until my wife is home and then get her to read off an SMS code for me.

But that's the thing: SMS can be auto-forwarded without that much effort. Definitely without rooting your phone. I don't recall if there is any built-in functionality for this, or at what granularity, but in the past I had a Tasker profile specifically meant to forward very specific SMS 2FA codes.

Now try that with a bank/vendor app. Or any other communication app. Nowadays, many don't even put the message body into the notification anymore, so you can't forward it via another channel (e.g. via SMS).

Yes, proprietary app-based authentication is the worst possible authentication scheme, but thankfully I don't need to use any services that insist on that.

Setup a Google voice number as her number in the system and have it forwards to you, with your wife's consent.

a) Google voice doesn't operate outside of the US, and I'm not aware of any equivalent that does, short of setting up, paying for, and managing a full-fledged voip line (e.g. with voip.ms) which are pretty finicky with 2FA codes.

b) These systems are a general pain when you need to deal with human support if your number on file doesn't match the number you call them from. I have a few different numbers that I use variously and run into this every so often - I get a barrage of extra verification questions if I call from a non-matching number, callbacks seem to happen randomly between my number on file vs. my number listed in a ticket, etc. My wife teases me about constantly breaking systems due to hitting untested edge cases.

(Tangentially, various systems will require you to input a phone number with no information stating that it must be a number capable of receiving texts, and at some future date will try to send your landline authentication codes via SMS.)

Except for Microsoft, who just sort of scale back MFA (unless you pay for Microsoft 365 Pro Gold Deluxe Plus Platinum Millenium Edition E5 to set the policy that used to be free) because of reasons.

It's usually a way to make users pay more and regularly, but when it comes to things like extensions in firefox... I just start to think they actually think it actually improves security lol. Cuz why would you even restrict me from loading any extension I want? Nobody buys extensions, nobody pirates them.

IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.

"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.

> Better things aren't possible

Literally no one in security thinks this.

In what way are Passkeys, as implemented (not theoretical benefits), better than passwords?

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're better for both parties with the subset of providers who require one of either SMS 2FA or passkeys.

They're better in some ways. They don't rely on a secret with low entropy which is really brute forceable. They can't be used on a phishing site because the URL is part of the secret. Even when you authenticate to a fake site you don't give them the ability to authenticate as you until you change the secret (like you do when you give them your password)

They also have 2fa built in. No need for a separate app, entering codes whatever.

That's why I mentioned "and also enabling authorised access to that same resource". Passkeys are great at preventing unauthorized access. But that comes at the expense of preventing authorised access. For example, using another device or even moving to another device. Replacing a stolen or damaged device is also nearly impossible with a reasonable quantity of Passkeys.

Well that's why they can sync between devices. I don't really see the problem.

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.

KeepassXC now supports Passkeys? All right then, I accept that argument. I do use Keepass and compatible programs.

Yes! Though on Android you need the app KeePassDX to read them, I was mistaken about the name.

> Well that's why they can sync between devices. I don't really see the problem.

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?

Yes you can do that with Bitwarden or KeepassXC.

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).

Great, thanks.

> There have been real improvements in this space, such as passkeys

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.

Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.

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.

> Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.

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.

> It means more electricity, more compute, more money spent.

And it means more middlemen mediating people's access to their own tools.

Yes but the balance has shifted a lot.

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.

Given cyber attacks are more rampant than ever, it’s hard to argue that security has gone too far the other way.

Shifting the balance towards security doesn't always improve the overall security stance. 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. For example, I was at a highly secured facility one time as a vendor to do a software upgrade. Blocked USB ports, severely reduced internet access etc. So I couldn't do the upgrade, I wasn't even allowed near the server. Nor could I connect my laptop to their network. All sensible precautions but how do I then upgrade the server software?

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.

> Shifting the balance towards security doesn't always improve the overall security stance.

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.

> 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.

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.

You’re hugely over simplifying things.

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.

Well said, security enthusiasts don't understand that the optimal amount of security breaches is not zero.

It will be "so convenient" when we finally have digital ID so we won't have to deal with all that stuff.

Not until we clearly identify the deep root from which all of this is conveyed.

Wait until you figure out just how much trust is required to make Zero Trust work.

It is all so frustrating.

Reminds me of what Ubiquiti tried to pull a few weeks ago. They wanted to force everyone to their Cloud UI and login instead of the local interfaces so they reduced the local session lifetime to something insane like 20 minutes while lying to our faces and saying it is for security, and kept the session lifetime longer on their cloud panels. They made sure to exclude this from their changelog too.

The community started monkey patching their local scripts, wrote services to undo their changes, many people disabled auto-updates as Ubiquiti only makes their product worse with their updates. Publicly complained on their support forum that we are onto their little plot.

They ended up backtracking for now but you just know they will try again like Google does.

That's sad news. I've been a fan of Ubiquiti for a long time, and the main selling point has been that they're fully self-managed on-prem infrastructure, with cloud services being an optional afterthought. Seeing them succumb to this disease of using security as a pretext to strongarm their customers is very disheartening.

I had another vendor try to use this argument with us just last week, and I had to vigorously remind them that they were not hired as a security contractor, and that our usage of their product was required to conform to our security policies, not theirs.