[fph]

This assumes that the banking app receives push data about the transaction by the bank, and simply has an "approve" button A simple 2FA app like Authy/Aegis that produces a number has the same problems as the keyfob.

The threat model is: malicious actor posing as the bank website, but legitimate keyfob or legitimate app. With the keyfob, the website intercepts a valid password and a valid 2FA code; with the app, nothing happens because it doesn't receive push data from the true bank.

I hope it is more clear now!

[Terr_]

> with the app, nothing happens because it doesn't receive push data from the true bank.

I don't see how that feature matters to a man in the middle attack during logon, since:

1. User opens web browser at a phishing site, which is masquerading as their bank, and starts the login process.

2. Phishing site interacts with bank.

3. Bank sends push-notification to the phone# that's on-file for that user: "Hey, that you logging in right now? Press the Yes button if so."

4. User sees it, expects it, presses the button, and then proceeds to hand over their TOTP and password to the phishing site anyway.

I suppose it might help on a per-transaction basis if the phishing site tries to trigger a hidden transaction, but at that point the app is just a way to streamline: "We sent you a code by SMS, enter that code to confirm the transaction."

[fph]

The point is that the app displays data on the transaction. If the phishing site tries to trigger a hidden transaction (or modify one that you are entering), you can review amount, recipient, and description _on the app_.