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.
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.
I'm not an Android developer, but I was thinking they could use something like the android.os.Build.VERSION.SECURITY_PATCH call to get the security patch level. Maybe that's not sufficient for that purpose, though.
Even then, two things turn out to be true:
- Banks don't actually want to put in the effort and deal with angry customers with slightly-out-of-date devices.
- All the credential-stealing malware on Android works perfectly fine on stock, unmodified, non-rooted OS images anyway. They just need to socially-engineer the user to grant accessibility permissions to the malicious app.
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.
I'm not convinced this is generally true, at least as can be detected by an app. Back when I had my phone rooted, it was configured so that it would pass all the Google checks and look like the stock OS. That configuration was probably dangerous, but apps were happy with it. Now that I run an OS that doesn't lie about what it is, I'm flagged as untrustworthy. What's the point in being honest?
Overall, I don't think they really have any idea what's a threat based on the checks they're doing, so I don't think they can say at all what's more or less trustworthy. But I think that a phone that reports being years out of date should reasonably not be expected to be secure, but yet they mark it as secure anyway. Many of those devices can be rooted in a way that can still pass their checks. I would think, if nothing else, that would be reason to block them, since they're interested in blocking rooted devices.
That's just straight-up false ; the phone without security updates has known exploits its user knows nothing about (and certainly not how to avoid them). The phone with an unknown OS has a user capable of installing said OS, at the very least.
Also in my experience a rooted phone experience is by far more secure than the OEM androids. Security is supposed to assess risk objectively, yet "running on a Xiaomi phone with 3rd party apps that cannot be uninstalled and have system access" is somehow more secure than "running on a signed LineageOS where user can edit hosts file".
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.
Agreed on everything you said. Just wish there was a more efficient way to do things :/
Unfortunately, some banks do, for various functionality; there are many things you can do via bank apps and not typically via their website.
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.
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.
GrapheneOS is not rooted, or is not required to be.
I know some people have issues with Duo, I don't, with pager duty i _just_ installed th last version from Play store, logged in with sso to my org and I'm in, can do or see everything.
Maybe it's play services in your case, not play integrity? I'm on the last release from the stable channel.
Unfortunately, the rot runs too deep.
Pick up the can!
Gotta admit, this triggered me. I don’t think those are the same thing. If no one had a good password we wouldn’t affect each other negatively. If no one picked up trash, we would.
Edit: Sorry folks, didn’t get the reference.
The GP is equating policies for strong passwords that aren't trivially cracked with authoritarianism.
If no one had a good password, we actually would affect each other negatively. If your personal banker can be easily compromised, that means that you could be easily parted with your money.
I do agree that they are not the same thing.
Incorrect - the requirements I mentioned make passwords less memorable and less secure (maximum length 12???). Obviously that's not as bad as authoritarianism, but I was trying to capture the arbitrary act being forced on us for no real justifiable reason.
And not using special chars is cheap, as by requiring a min-length of 13 instead of 12, you can get an even greater level of security.
A properly-coded system wouldn't care, but the people who write the rules have read old OWASP documents and in there they saw these symbols were somehow involved in big scary hacks that they didn't understand. So it's easier to ban them.
They would not believe I was creating an account and using the device, because their own logging was so terrible.
I had to send them a screen recording from me using this abomination, and only then was I told "you're using the wrong special characters". They helpfully gave me some examples of allowed special characters, which then would pass the server validation.
I wish they would have gotten rid of the account requirement, as the device and client software seemed to work fine without them.
With rainbow tables, even 11-character simple passwords like 'password123' can be trivially cracked, and as the number of password leaks show, not everyone is great at managing secrets and credentials.
The amount of times people have complained to me that this doesn't work because of low max-chars on passwords is insane.
Uh4zB4DP55WD!
Apparently I was a bit salty with the system when I set it.
The fact that she shouldn't have even been able to look up the password in the first place due to hashing was lost on her.
Would using the password you gain through this social engineering be doubly illegal?
At this point I wouldn't be surprised if there exists a system that just asks for username with a checkbox "check here if you are the owner of this account"
I started using passphrases after I saw this xkcd https://xkcd.com/936/
When I'm trying to log into something on a device that has a terrible keyboard, like a TV or giant touchscreen, it's a lot easier to type words I know than gibberish.
On password length, I once had an account on Aetna that let me put whatever I want for my password, so I used a three-word passphrase that bitwarden generated for me. It ended up being like 20 chars.
Then I tried to log in with that password. Whooosies, the password input only allowed max 16 chars!
Ended up using a much less secure password because of this.
"Hey idiot, I'm storing your password in plaintext, don't know anything about password security, and I'm also going to make you pick something you can't remember for 'security'."