[madeforhnyo]

A collegue of mine was tech lead at a large online bank. For the mobile app, the first and foremost threat that security auditors would find was "The app runs on a rooted phone!!!". Security theater at its finest, checkboxes gotta be checked. The irony is that the devs were using rooted phones for QA and debugging.

[protimewaster]

Meanwhile, it's probably A-OK for the app to run on a phone that hasn't received security updates for 5 years.

I don't get it. If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?

I'm guessing it's because there are a lot of phones floating around that aren't updated (probably far more than are rooted), and they're willing to pretend to be secure when it impacts a small number of users but not willing to pretend to be secure when it impacts many users.

[maxloh]

Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years. For example, a malicious OS maker could add their own certificate to the root store, essentially allowing them to MitM all the traffic you send to the bank.

Liability works on the principle that "if it's good enough for Google, it's good enough for me." A bank cannot realistically vet every vendor, so they rely on the OS maker to do the heavy lifting.

Even if they wanted to trust a third-party OS, they would need to review them on a case-by-case basis. A hobbyist OS compiled by a random volunteer would almost certainly be rejected.

[tadfisher]

> If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?

Google doesn't provide an API or data set to figure out what the current security patch level is for any particular device. Officially, OEMs can now be 4 months out-of-date, and user updates lag behind that.

Your guess is good, but misses the point. Banks are worried about a couple things with mobile clients: credential stealing and application spoofing. As a consequence, the banks want to ensure that the thing connecting to their client API is an unmodified first-party application. The only way to accomplish this with any sort of confidence is to use hardware attestation, which requires a secure chain-of-trust from the hardware TEE/TPM, to the bootloader, to the system OS, and finally to your application.

So you need a way for security people working for banks to feel confident that it's the bank's code which is operating on the user's behalf to do things like transfer money. They care less about exploits for unsupported devices, and it's inconvenient to users if they can't make payments from their five-year-old device.

And this is why Web Environment Integrity and friends should never be allowed to exist, because Android is the perfect cautionary tale of what banks will do with trusted-computing features: which is, the laziest possible thing that technically works, and keeps their support phone lines open.

[neumann]

It's more frustrating because my partner's pixel 4A cannot use google pay or the bank apps because it is an invalid os - I am guessing due to lack of updates? So, perfectly fine hardware, but crippled in functionality due to the lack of software updates.

[zobzu]

ive seen: -"but ios can be jailbroken and it doesnt have an AV!" while the MDM does not allow jailbroken devices, and they also allowed sudo on linux.

auditors are clueless parasites as far as im concerned. the whole thing is always a charade where the compliance team, who barely knows any better tries to lie to yhe auditor, and the auditor pick random items they dont understand anyway. waste of time, money and humans.

[virtue3]

at best it's "cover your ass security" so when you do get pwned you can say you went through an "accrediting auditor" - blah blah blah.

Agreed on everything you said. Just wish there was a more efficient way to do things :/

[dlcarrier]

As long as copying some numbers, printed on a piece of plastic, into an online order form is all the authentication that is needed for a transaction, anything more than that is inherently security theater.

[rahkiin]

That’s why for most transactions I do with a credit card in my country, you need an extra validation with the mobile app. It is mostly American websites that do not enable this functionality.

[sunaookami]

Yeah that's the first thing a pentest will complain about, had the same problem too. I pushed back enough so that it's trivial to bypass but the bank and pentesters also agreed with me that it's security theater or else I would never had the chance.

[hparadiz]

I always ask them if they have root/admin on their computer. Then follow up playing dumb with "shouldn't we lock out PCs too?". Watching them stammer is worth the 30 second aside.

[bnjms]

Who do we lobby to get this removed from the auditors checklists? This is a solvable problem but it’s political. And if we don’t solve it personal computing is at risk.

[prasadjoglekar]

Start by calling (or visiting the area office of) your senator and congressman. If you are reasonably articulate, they engage and listen. Doesn't matter if the listener is not a techie; they will ask questions around policy and why it affects constituents.

This is 1000x more useful than online petitions or other passive stuff. Politicians know that one person to have taken the effort to do this, means 1000 others are feeling the same thing but are quiet.

[monksy]

A lot of that is security theater at its best. However given the forced attack surface I would imagine that there is a hard push from authoritarians and the finance world to make a "secure chain" from service to screen.

My guess: They're afraid that the scammers are going to mirror the screen and remote control access to the app. (More orgs are moving to app/phone based assumptions because it saves the org money and pushes cost on the consumer) Instead of providing protections from account take over.. we're going to get devices we don't own and we have to to pay for, maintain and pay for services to get a terminal to your own bank account. Additionally, there are many dictatorships, like the UK, North Korea, etc, that are very adimate that you don't look at things without their permission. So they're trying to close the gap of avoiding age verification bypasses with VPNs.

[mmooss]

> the first and foremost threat that security auditors would find was "The app runs on a rooted phone!!!".

GrapheneOS is not rooted, or is not required to be.

[tranq_cassowary]

Moreso, the project advises against rooting your phone and tells you that if you install GrapheneOS and root it that you aren't running GrapheneOS anymore.

[subscribed]

No it's not, but it's bundled in the same basket. "Didn't pass DEVICE_INTEGRITY -> rooted"

[NewJazz]

But grapheneos doesn't need to be rooted!

[HybridStatAnim8]

Unfortunately, root detection is greatly flawed, most of the time.

[ACCount37]

Oh how I fucking wish "security" wasn't a stupid cargo cult checkbox list 3/4 of the times.

Unfortunately, the rot runs too deep.

[empyrrhicist]

Your password must be between 8 and 12 characters, and must have lowercase, uppercase, numbers, and punctuation.

Pick up the can!