Hacker News Reader

Comment by jaclaz | Hacker News Reader

This is something I still cannot understand, in the sense that usually the procedure is the following, at least with my bank (that uses SMS OTP):

On the website:

1. you input a user ID

2. you input a password or PIN

3. you press a button that sends a SMS with an OTP code to the registered cellular number

4. you input this OTP code on the site

Even if someone can intercept the SMS, they wouldn't (shouldn't) have ID and PIN.

View on HN

For one thing, there are a lot of security holes that let people reset passwords by getting a code via SMS

For another, what's the point in having 2FA if one of the factors is completely insecure? It's just an annoyance at that point, and a good way to ... tie your account to your phone number, which just coincidentally happens to be the primary key for most advertising tracking services. What a coincidence

By that logic, you don't need an OTP code at all, because your adversary "shouldn't" have your password or PIN.

The entire point of two-factor authentication is to provide an extra layer of security for when the first layer is compromised.

I think the logic is the same.

Having the possibility/capability of intercepting the SMS is only effective if the ID and PIN are already known, and while surely there are "other" ways to get them, the attacker needs all three.

From what I have read/seen, most if not all successful attempts to access someone else's bank account online go through some form of phishing.

Not only phishing, but too many people have the terrible habit of using the same password everywhere. So with public breach data, it's not a stretch to think bad actors would try, and probably be successful way too often, to use said credentials on bank sites.

Assume for all these attacks that the user has been first thoroughly keylogged via malware or had all static credentials stolen first via leak or phishing.

The SIMjacking is the last barrier to access.

In most cases people reuse passwords and their login/password are known via any number of a million dumps of large websites whose dbs have been breached.

You build a fake website. The victim enters their ID and password. The fake website asks for the SMS TAN. The victim gets an SMS from the actual bank and enters the TAN. Profit.

It doesn't have any security benefit for phishing like this, it's just one additional password input field.

Sure, but in this case, like in many "phishing" schemes, there is no interception of the SMS, this same approach applies to all other authentication tokens, as it is the victim that enters the OTP on the (fake) site or communicates it to the phisher who calls impersonating a bank employee.

> this same approach applies to all other authentication tokens

Not true. FIDO and prevents this. The key is bound to the site you authorized it on, so inputting the key while connected to a phishing site will do nothing.

* https://www.yubico.com/authentication-standards/fido-u2f/

Yes, I meant those (I believe much more common) various hardware token generators and those "in-app" ones (issued by the bank), that end up as a 6 or 8 digits that you have to type on the site.

Reply on news.ycombinator.com