Comment

Comment by dools

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 addition of a new "pay anyone" payee, and with that her money was gone[0].

I have accounts with 2 banks, one uses SMS 2fa and the other uses an app which generates a token. I had thought that the app was by default a better choice because of the inherent lack of security in SMS as a protcol BUT in the above attack the bank that sends the SMS would have been better because they send a different message when you're doing a transfer to a new payee than when you're logging in.

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. I haven't seen any bank with that level of 2fa yet, has anyone else?

I guess perhaps passkeys make this obsolete anyway since it establishes a local physical connection to a piece of hardware.

[0] Ron Howard voice: "she eventually got it back"

parent dools 2 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton