A family friend of ours recently fell victim to a phishing attack perpetrated by an attacker who paid for Google Ads for a search term like "BANKNAME login". The site was an immaculate knock off, with a replay attack in the background. She entered her 2fa code from the app on her phone but the interface rejected the code and asked her for another one. In the background, this 2nd code was actually to authorise the add…
> So really the ideal is not just having an app that generates a token but one that generates a specific type of token depending on what type of transaction you're performing and won't accept, for example, a login token when adding a new payee. My understanding of EU regulation is that it effectively requires this by requiring the 2FA to validate not just the identity but also the transaction (such as an amount, or d…
The most elegant implementation I saw of this were card readers with a 2D (colored) barcode scan ; the 2D barcode contained transaction details that the card reader would display on its screen. This was an effective control against MITM. But even I myself always misplaced the card reader.
So now, most confirmations are done using the banking app. Even if I use a credit card by filling in its details on a US website, I get a push notification on my phone to confirm the tx on my app.
The app asks for a password or uses biometrics, so thats 1FA, and the app is enrolled at some point, so the token on your phone (I presume in some secure storage) counts as the 'thing you have' for 2FA.
Enrolling the app nowadays usually entails scanning your ID card and a 'live selfie' (blink your eyes). And of course you get notified (via e-mail) that you just installed the app on some device.