You shouldn't need a separate device, but we are quickly entering an era where a lot of banking (and other) apps will outright refuse to run or allow logins if it detects a rooted device, or play integrity fails.

In this way, the banks are asserting control over your device. It's beyond authentication, they are saying "If you have full control over your device, you cannot access our services."

I'll agree with you that they don't have a valid position, because I can just as easily open up a web browser on said rooted device and access just fine via the web, but how long until services move away from web interfaces in favor of apps instead to assert more control?

I have to use my phone to approve the web login to my account. My bank is working very hard to make sure that everyone uses the app for everything, including closing down offices and removing ATMs around the city.

A hardware token would not suffice. When you login with a hardware token it will generate some sort of token or cookie for further requests. This is where malware can steal that key and use it for whatever it wants. There is a benefit it knowing there is a high chance that the such a key is protected by the operating system's sandboxing technology. Without remote attestation you don't know if the sandbox is actually active or not.

On the contrary, a hardware token will suffice to thwart both phising and MitM which covers ~everything for all practical threat and liability models. What exactly is the concern here? A widespread worm that no one is yet aware of that's dumping people's bank accounts into crypto? It might make for a decent Hollywood plot but is pulling that off actually easier than attacking the bank directly?

Keep in mind that the businesses pushing this stuff still don't support U2F by and large. When I can go down in person to enroll a hardware token I might maybe consider listening to what they have to say on the subject. Maybe. (But probably not.)

Hypothetically on a fully controlled system you could prevent attacks like the sort of “hello this is Microsoft, we’ve identified a virus on your device, please download teamviewer and login to your bank account so we can clear it for you” type spam calls.

Or, hasn’t there been malware that periodically takes screenshots of the device? Or maybe that’s a Hollywood plot, I forget actually.

Keep in mind that a truly clueless user will most likely be running in a stock configuration. So long as that doesn't permit apps to tamper with one another (as is currently the case) there should be no issue. Google could even provide a toggle to officially root the phone and so long as flipping it wiped the device the problem would remain 99.9% solved because a scammer would be unable to pull the job off in one go.

By the time you reach the point that the user is doggedly following harmful step by step instructions over the course of multiple callbacks there is nothing short of a padded cell that can protect him from himself.

Unless you mean to suggest somehow screening such calls? A local LLM? Literal wiretapping via realtime upload to the cloud? If facing such a route society would likely be better off institutionalizing anyone victimized in such a manner.

> hasn’t there been malware that periodically takes screenshots of the device?

Yeah, it's called Recall and its baked into Windows as a "feature."

It's unfortunate because it's actually incredibly useful functionality. If only they hadn't packaged and marketed it in quite the way they did. If there was ever a feature that needed to be guaranteed local only, zero third party integration, zero first party analytics, encryption tied to a TPM that was it.

How does it solve MITM? You type your hardware token in and then an attacker uses it to send money out of your account.

>What exactly is the concern here?

Stealer malware. Or even RATs where attackers get notified when you open a sensitive app and they can take over after you have authenticated.

Could you please spell out the specifics of this scenario?

MitM via an evil (ie incorrect) domain name is prevented because U2F (and now webauthn or CTAP2) are origin bound.

RATs? On stock android? How does that work? And how are the things you describe not also threats for online banking via a browser? It's certainly not how the vast majority of attacks take place in the wild. Can you provide any examples of such an attack (ie malware as opposed to phishing) that was widespread? Otherwise I assume we're writing a script for Hollywood here.

Even then, a RAT could be trivially defeated by requiring a second one-off token authentication for any transaction that would move money around. I doubt there'd be much objection to such a policy. If people really hate it let them opt out below an amount of their choosing by signing a liability waiver.

>are origin bound.

This is assuming the user's device is not compromised.

>How does that work?

Priviledge escalation on an old OS version allows an attacker to get root access. Then with that they can bypass any sandboxing. Or they could get access to some android permission intended for system apps that they should not have access to and use that to do malicous things.

I don't closely follow malware outbreaks for android so I can't point to specific examples, but malware does exist.

So the attacker compromises the user's device ... and then sets up a MitM? This is making about as much sense as the typical Hollywood plot that involves computers so I guess that means we're on track.

> Priviledge escalation on an old OS version allows an attacker to get root access.

At which point hardware attestation accomplishes nothing. Running in an enclave might but attesting the OS image that was used to boot most certainly won't.

Many consumers use older devices. Any banking app is forced to support them or they will lose customers. There's no way around that. (It doesn't matter anyway because these sorts of attacks simply aren't commonplace.)

> but malware does exist.

I didn't ask for an example of malware. I asked you to point to an example of a widespread attack against secured accounts using malware as a vector. You have invented some utterly unrealistic scenario that simply isn't a concern in the real world for a consumer banking interaction.

You're describing the sort of high effort targeted attack utilizing one or more zero days that a high level government official might be subject to.

>At which point hardware attestation accomplishes nothing

Attestation could be used to say that the user is not using a secure version of the OS That has known vulnerabilities patched.

>Any banking app is forced to support them or they will lose customers.

Remote attestation is just one of the many signals used for detecting fraud.

>one or more zero days

Many phones are not on an OS getting security updates. Whether that be due to age or the vendor not distributing the security patches. Even using old exploits malware can work.