Android is getting just as bad lately. My primary banking app (Barclays) just stopped working on my phone because they've started to use Android hardware attested SafetyNet[0][1] to check to see if the phone is rooted.
This can't be easily bypassed. Magisk Hide is useless. For now I've had to disable auto-updates in the Play Store and manually install an older app APK, but it's only a matter of time before they deprecate that version. I do essentially all of my banking via my phone, so when this happens I intend to close all my accounts and move banks.
The sooner someone leaks a hardware key (preferably one that Google can't revoke without cripplingly bad PR for breaking millions of products) the better.
I honestly think 'appification', app stores, and locked down hardware via key chains will be the end of an era in hacker-friendly consumer electronics. Perhaps the end of personal computing entirely.
Both white and black hat hackers friendly? The vast majority of consumers don't want to 'hack' their device. They just want to watch Youtube and do bank payments without getting hacked and robbed of their savings. Recently there was another case in the news where someone was phished via an insecure platform (PC).
I get that a lot of rights are taken away from us, but we should fight this with proper consumer protection laws. As it is demonstrated times again most consumers are to naive to take responsability of their security and criminals get away with it to easily.
Several other apps I use simply display a warning when used on a rooted device. Ultimately, the problem here is one of recommendation vs enforcement.
Would you tolerate a bank that insisted on coming in to your house and forcing you to install Norton Antivirus on your computer before they allowed you to log on to your online banking via their website?
Banking security should be implemented on the server side. I shouldn't have to choose between running my own code as root on my device and being able to bank.
You could ask that question the other way around. Should the bank allow people to put up a fake front for the ATM recording the customers card and PIN?
Not all problems can be solved server side. And no bank is going to come into anyones house. But they need a resonable assurance the environment the customer uses to conduct their bussines in safe and trustworthy. It's either that or no mobile customer service at all. Or everyone needs a "digital drivers licence" which I think some "IT people" I know wouldn't even pass for.
Phishing is a real threat. It might never ever happen to you. But a lot of people thought just that and got phished anyways because they where learned to trust certain signs (eg: green padlocks).
> Should the bank allow people to put up a fake front for the ATM recording the customers card and PIN?
This is a false dichotomy. The hardware attestation for SafetyNet is orthogonal to being able to use hardware attestation for e.g. session/user keys, or even chain-of-trust down to the fingerprint sensor level.
Keys can be kept secure using secure enclaves even if the OS is rooted.
Blocking rooted phones with SafetyNet is just spite.
Not to mention, an ATM is property of the bank and is shared-use. The user is not the owner. The phone belongs to the user.
This can't be easily bypassed. Magisk Hide is useless. For now I've had to disable auto-updates in the Play Store and manually install an older app APK, but it's only a matter of time before they deprecate that version. I do essentially all of my banking via my phone, so when this happens I intend to close all my accounts and move banks.
The sooner someone leaks a hardware key (preferably one that Google can't revoke without cripplingly bad PR for breaking millions of products) the better.
I honestly think 'appification', app stores, and locked down hardware via key chains will be the end of an era in hacker-friendly consumer electronics. Perhaps the end of personal computing entirely.
[0] https://developer.android.com/training/safetynet/attestation...
[1] https://groups.google.com/g/safetynet-api-clients/c/lpDXBNeV...