[acdha]

> The system - whose security I trust much more than a phone's - uses a small device with a camera. The login screen shows me a pattern with colored dots. The camera reads those dots, decodes the message (and probably also validates it cryptographically) and displays a message asking me to verify I want to log in.

> I enter the PIN, and it generates a response code, which I enter.

How do they protect against phishing? That sounds like the weak MFA where attacks spoof the login page but make their own connection to your bank and pass through the challenge and response, which means that a user who doesn’t fastidiously check the hostname can be convinced to enter a TOTP, SMS, etc. code.

Phone-based WebAuthn systems are immune to that because they incorporate the hostname into the signing process so even if they convince you that they’re hugeb<cyrillic a>nk.com there’s no way for you to override that and give it a response which works for hugebank.com.

[dalke]

> How do they protect against phishing?

The same way they minimize the vulnerability when running on an exploited Windows machine?

Even if I log in, via a MITM attack, all they can do is read my account history.

Actually making changes requires further authorization. When I make a payment the screen asks me to confirm the amount I'm about to pay. The same applies to other security sensitive changes.

Still, you make a very valid point, and I thank you for pointing out the flaw in my understanding.

I still have a very deep distrust about centralizing identification, payment, and apps on a single device, and strongly dislike the inability to have physically very distinct trust levels.

[acdha]

> Actually making changes requires further authorization. When I make a payment the screen asks me to confirm the amount I'm about to pay. The same applies to other security sensitive changes.

That’s a good answer, too, especially of that custom message can be large enough to display the name & amount. Anything to jar people out of the “I thought I was sending $100 to the cable TV company, not $6,000 to someone in India” autopilot state.

I generally agree with your larger point and wish that banks would make it easier to do things like setup a Yubikey and require it be used on any transaction over a certain amount. I’ve never in my life needed to make a large transaction where I wouldn’t have been able to grab a token from my safe to approve it, and at some point delay becomes a security feature since it give the bank staff time to do things like call you and make sure you really intended to do something.

[dalke]

Thank you for your supportive words.

Certainly seeing articles like this about possible flaws in a centralized system, and the last of economic responsibility for fixing issues in affected customers, ... about people losing their Google id, the monopoly abuses of Google and Apple, and the e-waste issues of depending on apps which don't support old-but-working phones (sometimes in the name of security, but more often because it's expensive to maintain old phones) ... really gives me a bad feeling about this brave new world.

[dalke]

> Phone-based WebAuthn systems are immune to that

Do they assume the OS is locked down and secure?

I mean, clearly if someone has a remote desktop view for my machine, then they can act as me, including any check for available hardware. The same should apply for a phone, yes?

If so, that sounds like my bank will never formally support running on a PinePhone or other user-inspectable/modifiable system - they will simply say they require a full chain of trust for the OS.

I'm glad the (relatively) open arenas of macOS and Windows existing, and that people have 10+-year-old machines, forcing my bank to support alternate login methods for less-trustworthy systems.