Second factor SMS: Worse than its reputation

Why isn't there any market fulfillment for "safe, non-intrusive ads", on the part of a vendor? Is it because it's not possible, or not worth the overhead either because of cost or no effect on consumer behavior/blocking?

This seems like it ought to be low-hanging fruit. I would have less aversion to clicking on ads if I did not default to it being a security risk.

It's to the point that even the US government (even with all its faults and lobbying) recommends using an ad blocker for this reason.

TIP: I sold my senior mom on uBlock Origin because YT ads are so obnoxious. The added benefits are extra security and performance improvements. She was even able to understand that if something doesn't seem to be working right (like a banking site) "turn it off and try again".

This might not be sufficient anymore. Many online payments are rendered either on the shop's pages or on a third party payment provider, including 3DSecure implementations. These don't redirect to any sensible bank URLs.

Both of my banks use a payment flow which uses a hardware authenticator. But only one bank seems secure: it prompts for an amount and a reference and generates an OTP based on that. This is distinct from any other signing operations with the same authenticator. The other bank tells me to enter a 6 digit number (which is allegedly made up out of a part of the amount and a reference), but it is impossible to tell this apart from any other signing operation. It doesn't strike me as too hard to abuse that to either log in to my account, to sign another payment, or even to create a direct debit...

In the past I've heard people say the opposite - that if less computer savvy people are using google instead of URLs, it's a good thing.

The reasoning was it protects them against typosquatters and whitehouse.com situations. I guess when people were giving out that advice, google wasn't the way it is now.

I'd like to throw a little blame onto many namebrand websites.

Sites like Digital Ocean try to load dozens of third-party trackers for a single page. Their supposedly secure payment processing includes cross-site violations that are blocked by modern browsers.

When their credit card management pages fail to work with reasonable browser defaults or sane browser add-ons they immediately advise their users to strip out all security protections. You are supposed to just trust content coming from seemingly unrelated domains including multiple processors you may or may not have ever heard of. Paypal? Ok, plausible. Stripe? I guess, but both? Pendo? Sentry? Optimizely? Hexagon? Google Ads? Google Analytics? Six other different Paypal domains? Eight other Stripe domains? Multiple Typekit domains? TagManager? Spuare? The list keeps going.

Plenty of reasonable protections cause alarm bells left and right. The answer? Disable those protections. Train users to think they are the problem.

Also that Google, as a search engine that is also the world's biggest advertising company really should be able to manage not to sell ads to phishing scammers!

Or skip the website and use their native app.

Very difficult with most big banks.

In my experience with Bank of America and US Bank they bounce you around to several totally different top level domains as you navigate through the web-based banking.

These are third-party service providers that the banks contract for various pieces of their online infra… And it is a complete mess in terms of conditioning consumers to be phished.

If Google ad words even allows a scammer to create an ad for a bank login page then we have a more fundamental problem.

Because the impersonator is probably a lot more sophisticated at this than you or I, and it's likely that 999 impersonators were rejected and this is just the 1/1000 who found a way around it.

The system probably produces a lot of false positives AND negatives.

Don’t they usually put in “legitimate” ads and info then swap out the content afterwards with the spamscam?

I'd guess the phishers spent a lot of time and burned some google adwords accounts looking for what would get through any automated checks they had.

I once tried to buy a domain which contained the word "Google" from Namecheap, but I was rejected with an error telling me that I needed to contact support and show that my use of the trademark was approved by Google. So instead I went to Google Domains and bought it from them with no issues.

Criminals are incentivized to evade detection. And you only get to observe the successful criminals and none of the unsuccessful ones. This makes it appear like the criminals are getting through the filters trivially. What you don't see is the work they are putting in to get a successful phishing ad up there.

Not to excuse failures, but there isn't a "it is easy for them but hard for me" situation.

My EU bank uses an app for consumer accounts. It hasn’t used sms for a few years, except when setting the app up on a new phone/sim.

Yes, the Payment Services Directive requires "dynamic linking" to a specific amount and a specific payee in article 97, and the RTS in article 5 go on to say that the payer should be "made aware of the amount of the payment transaction and of the payee".

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.

Unfortunately it means that all banks use SMS

This is not true, I have used multiple financial things where they have different codes for different uses (Raiffeisen, K&H) or apps which have a server sent event and local approval showing the transaction (wise, Fineco)

Nope. Apple participates in the same pay-for-search-placement scheme, and therefore will happily distribute the same kinds of scams. https://usa.kaspersky.com/blog/dangerous-apps-in-app-store/2...

Another step everyone will ignore because it isn't a problem for any particular person until it is.

When a measure becomes a target, it ceases to be a useful measure.

I feel like PassKeys and browser-integrated password managers both solve this problem better already. And yeah they're extra things to do, but so is this.

I'm not familiar with the nuances of terminology, but I would expect MITM to only apply when you (and your computer) actually attempt to connect to service A, and a malicious actor X intercepts that communication. Phishing is different in the sense that you connect to the phishing page directly, and it may or may not replay some of your inputs to the actual service it is phishing.

I called this a "replay attack" because it sounds more like this:

"A replay attack in a network communications setting involves intercepting a successful authentication process—often using a valid session token that gives a particular user access to the network—and replaying that authentication to the network to gain access"

Even though this wasn't a session token, it was an authentication process and token, gathered from a fraudlent source and replayed to a valid source.

MITM is:

"A man in the middle (MITM) attack is a general term for when a perpetrator positions himself in a conversation between a user and an application—either to eavesdrop or to impersonate one of the parties, making it appear as if a normal exchange of information is underway."

So to me a MITM would be more like using a wifi access point to access the correct banking URL, but the service carrying the data was acting maliciously.

My gut? It actually works, and people didn't like that. Users and orgs like authentication slightly broken so they can work around systems.

People like authentication systems that are secure enough to keep bad actors out, but not so secure that it keeps legitimate users out. It's got nothing to do with users wanting to break into a system.

I like FIDO U2F as a second factor, although you always need a fallback of some kind in case you are stuck using a device without a USB port. I don't like it as a single factor, as most devices make it hard or impossible to back up your keys. Using Passkeys with Bitwarden is pretty interesting though, and appears to satisfy most of my concerns, as they're just stored in my password manager and move devices with me.

It only works in a couple of situations and it's difficult to manage. When the site doesn't support it (which is almost all of them), when you don't have USB, when you lose or forget your YubiKey, when you don't have a phone with NFC or lose it, when you can't afford the device, or it's difficult for the user to set up, etc it fails. Now you need a different factor to finish logging in, which is probably weaker, so attackers will try to degrade this first factor to force the second weaker one.

It's a nice-to-have but not even close to a universal solution.

For a long time (still?) Kraken also refused to add SMS 2FA as an option due to its weak security.

I still don't see how that's worse than no 2FA at all, which was an option, but I appreciated that they were banging the "SMS 2FA isn't very secure" drum.

What's your process? Where do you save the cert? I'd be interested in automating that.

Was this in the US or elsewhere, what was the amount and how long did it take to notice? Just curious.

It was in Australia, amount was thousands of dollars, she noticed when she was asked to enter yet another code and all of a sudden it made her snap out of her "autopilot" and take notice and look at the URL and other details. So as soon as she realised that something was fishy, she logged into the correct site, then saw the money was gone.

In the US the bar to pull money out of an account is pretty low. Most banks would allow reasonably-sized transfers out with just routing and account numbers. I was stunned by this, but this is the reason utilities and stores can pull your money without you even talking to your bank. Just give them the info. And that information is not secret, it is printed on your every check. The flip size is that for those "convenience" and service payments the money is easy to get back: banks, at least traditional, will bend over backwards to prevent being seen as enabling fraud.

This was a "pay anyone" transfer. So money was being transferred to a bank by BSB/Account number in the background. The bank required a code when a new Payee is added, but the codes were not differentiated, so she was asked for a code to login, then told the code was wrong and asked for another code. In the background the real banking site to which her actions were being replaced had successfully logged in and had initiated a transfer to a new Payee. The real banking site asked the attackers for a code to add the new Payee, the fake banking site asked her for a new code to login.

The thing that really enabled the attack is that the same code generator was used for both codes, without any indication that a different action was being performed.

Because banks are financial institutions and every decision they make is based in that. If the cost of insurance is less than the cost to actually secure the system, they will choose that every time.

Banks and payment processors have some of the worst technical debt. For example, a lot of transactions are processed using the ISO8583 standard, a binary bitmap-based protocol from the 80s. The way cryptography was bolted onto this was the minimum required to meet auditing standards: specific fields are encrypted but 99% of the message is left plaintext without even an HMAC.

I am continually surprised that in a country as litiguous as the US companies can continue to sell advertising space and then just shrug when the buyer uses that space to defraud someone.

And why ads should be to the side at the very least and not mixed with search results

Yep. A few simple steps like an extra SMS (or email) code to add a recipient, an email notifying about the change, not perfect, but will make this harder to pull off. Not sure what is '"pay anyone" payee', i don't think it's a thing at my bank. They could try to scrape the account number though, I think in the States that may be enough to try to debit someone's account.

I read it as the first 2fa code was used to login, then the system quickly attempted to add this new payee which required a second 2fa code, so the phishing site quickly sends another request stating the code saying the first was rejected.

Luckily I had setup NextDNS to block newly registered domains along with a list of uncommon TLDs so the site got blocked.

I go further: I generate tens of thousands of variants of all the "sensitive" websites we use (like banks and brokers).

All the "levenshtein edit distance = 1" and some of the LED = 2. All variation of TLDs, etc.

I blocklist most TLDs (now that most are facetious): the entire TLD. I blocklist many countries both at the TLD level and by blocking their entire IP blocks (using ipsets).

For example for "keytradebank.be", I generate stuff like:

    # Generated by typosquat.clj for keytradebank.be (9809 entries)
    0.0.0.0 keeytraebank.be
    0.0.0.0 kebtradebank.be
    0.0.0.0 kytradebani.be
    0.0.0.0 keytrxdebak.be
    0.0.0.0 kewytadebank.be
    0.0.0.0 keytgadbank.be
    0.0.0.0 aeytradeank.be
    0.0.0.0 keytradebsan.be
    0.0.0.0 keymradebnk.be
    0.0.0.0 kytradeb9nk.be
    0.0.0.0 ketrade-bank.be
    0.0.0.0 keytradbeban.be
    0.0.0.0 eytradebafk.be
    0.0.0.0 keytraebank.ee
    0.0.0.0 keytrad3bak.be
    0.0.0.0 keytradebzn.be
    ...

I then force the browser to use the "corporate" DNS settings: where DoH/DoT is forbidden from the browser to the LAN DNS. I can still use DoH/DoT after that if I feel like it.

So any DNS request passes through the local DNS resolver (the firewall ensures that too).

My firewall also takes care of rejecting any DNS attempt to an internationalized domain names (by inspecting packets on port 53 and dropping any that contains "xn--"). I don't care a yota about the legit (for some definition of legit): "pile of poo heart" websites.

My local DNS resolver has 600 000 entries blocked I think, something like that.

I then also use a DNS resolver blocking known malware/porn sites (CloudFlare's 1.1.1.3 for example).

So copycat phishing sites have to dodge my blocklist, the usual blocklists (which I also put in my DNS), then 1.1.1.3's blocklist.

P.S: some people go further and block everything by default, then whitelist the sites they use. But it's a bit annoying to do with all the CDNs that have to be whitelisted etc.

I read those messages. The ones from one of my banks that uses SMS and differentiates them, says "your code to do BLAH is BLAH". I was actually saved from phishing once because my credit card company included the vendor and the amount in the transaction SMS and it was for a different site and a much larger amount than what I thought I was spending.

Yes, my AIB card reader works like this. When transferring money to an unknown account I also need to enter the amount and "sign" that with the card reader. For adding a new payee it's a challenge/response.

Well, that's what I'm saying. When I get an SMS from one of my banks for example it says "your code to transfer X to Y is ABC" or "Your code to add a new payee is ABC". In this case she had a code generating app, but the codes were not different for login versus other high risk actions. The same is true for my other bank, which has a code which you use to login, and the same code generator, with no distinction, is used for example when you make a large BPay transaction.

I believe it's the 3d secure protocol, my bank has it, usually a push notification or with a token.

When I tried to pay on a website a while ago I kept getting "unknown error". Fast forward about an hour waiting in the helpdesk phone queue, and turns out you need to set up a special password for that. This is not an "unknown" error, it's a known error... Why can't it just show me? Sigh.

I wonder how many people they've need to "help" with this. Yes, I know there's tons of old code in many banks, but they would have saved money if they had a single developer work on this full-time for a month or something. Support people may be cheaper than devs, but they're not free.

You can use Yubikeys, which are basically the modern and better version of "smart cards", on phones and tablets just fine. I have a Yubico Security Key on my keychain and I can use it on my iPhone with NFC or with my iPad using USB-C.

NFC/RFID in many mobile devices allows for interfacing smart cards very similarly to wired connection.

I don't quite understand that. It's not like sending an SMS to my phone is any more secure or harder to access than sending an email to my phone. Additionally, many seem to want a "real phone number", not a VoIP number like Google Voice.

Meanwhile treasurydirect.gov still just uses a verification code via email. If it's good enough for the Treasury, it's probably good enough for a bank.

since COVID, i've had 3 new numbers. i'm sure that's an edge case, but it happens. my second number came when I brought my own device to a pre-pay plan on a new carrier that said my number was not able to be ported. then, when i upgraded phones, the pre-pay number was not eligible for carrying over to the new device.

I know I'm not the first person to be unable to port a number, so calling a phone number something that never changes is a bit skewed

the new SSNs - unique identifiers that never change and connect you across services

And just like SSNs both the "unique" and the "never change" are only true of the spherical cow version of the system. Phone numbers are actually substantially worse at being unique and unchanging, what with people in families sharing a phone or trading phone numbers, people forgetting to transfer the number when switching carriers, people intentionally switching numbers in an attempt to end spam calls... The number of ways to break the assumed invariants is actually quite high.

See Falsehoods Programmers Believe About Phone Numbers [0].

[0] https://github.com/google/libphonenumber/blob/master/FALSEHO...

Only by those who never worked on these kind of services. Running something like a webmail service is being flypaper for dickheads. As soon as you gain any sort of popularity you will have some very hard and sharp lessons about the lengths spammers will go through to make abuse your service.

First rule of designing anything: "if some cunt can make a buck by completely fucking over your system then that cunt will completely fuck over your system because that cunt is a cunt."

Ugghhh, "frictionless" as if we're talking about logging into Candy Crush here. Are the "Growth Hackers" infiltrating banking apps now? I don't want my bank software to be frictionless. I want it to be secure.

Hot take: rooted phones are inherently less secure.

My computer is rooted, making it inherently less secure than my phone, yet I have no trouble accessing my bank website. What threat is a bank protecting against by disallowing app usage on a rooted phone?

There's always a root account, the only issue is who has access to it.

So... phones where a corporation has root are more secure that phones where the owner has root, you say? Secure for whom? For the user? Seems obviously wrong. It's more secure for someone else to have power over you?

Again, you're just a few words from "Freedom is slavery".

"Less secure" depends on your threat model.

I'm much less worried a hypothetical attack where I accidentally give sudo access to a malicious app than I am about the well-established ongoing attacks where Google violates the entire population's privacy, or the regular stream of malware that makes it into the official app store.

Hotter take: if you don't have root, you've been pwned.

Only if I grant them root, which I'd only do to a very small number of open source apps

I instead have to use my desktop web browser, and desktop operating systems have a far worse security model than Android. No special permissions are generally needed to capture the screen, capture/inject keystrokes, or open .mozilla/whatever/cookies.sqlite

So my phone is still the significantly more secure environment. The fact that I have the ability to grant root does not make it "compromised"

Bank apps not running on phones where security has been compromised seems entirely reasonable.

I have root access on my laptop and I log in to my bank's website just fine. Making apps not run on rooted phones is just perpetuating the cycle of forcing users to comply with the restrictions placed upon them by Apple and Google. Root access != less secure. It means control over the device you paid for and own.

Let’s not make an inferior solution mandatory when we already have a superior solution.

With a slight caveat that it doesn't work. At least not on Linux without some proprietary junk dongles or their emulators.

Would you agree also that MFA should be mandated for everybody's doors? Or to my bike?

Attacks in the digital world are simply more scalable than in real world. I can try to log into 1000 Gmail accounts in seconds, but it'll take me hours to try to open 1000 doors.

My front door effectively has 2FA.

You have to HAVE the key and you have to KNOW exactly how to wiggle the key to get it to work.

How I would loath to rely on Goole or Apple to be able to make payments or confirm other actions. Sure as hell they would call home about what actions I am performing, and associate that data with some Google account or Apple Id or so, that they will force me to have.

No thank you.

But it's also the most cost expensive (from provider side) among 1FA and 2FA-OTP

The linked article says that at the very end, in the very last sentence, just so they can evade this kind of discussion. Clearly the takeaway any regular user (also the typical too-pedantic-for-their-own-good HN commenter) is going to take away is clearly "Don't use SMS 2FA", and they will therefore make the wrong decision.

Use 2FA. Use 2FA. Use 2FA. Worry about the design decisions in your spare time.

I would argue that a 1FA unguessable password used once is just as good. Certainly better than the case where the provider offers account resets using just SMS thus having effectively 1FA SMS.

That really depends what else the company uses your number for now that you have given it to them for 2FA. Often enough it ends up being usable as a one factor for account "recovery".

I feel like you have two choices for password reset flows:

1. Insecure ones

2. Ones where many users needing recovery will get locked out with no ability to recover their accounts, guaranteed

most of them should be able to build their own service.

Isn't the hard prt the connectivity bit i.e. negotiating with the various telcos? I once saw a telco use a third party SMS vendor for messaging their own customers for an app - because setting it up internally was too much of a hassle.

We at MakePlans were affected by this breach as we use Twilio. We are not using Twilio Verify (their 2FA api) but rather handle 2FA SMS ourselves in our app using Twilio as one of our providers. So the CCC definition of this being only 2FA-SMS is incorrect, it was all SMS sent through this Twilio third party gateway that was exposed to a limited set of countries (France, Italy, Burkina Faso, Ivory Coast, and Gambia).

GDPR is not necessary applicable here. An SMS gateway is most likely classified as a telecom carrier, and thus any local telco laws would be applicable and not GDPR. That applies only to the transfer of the SMS though, so for example a customer GUI of sent SMS would be out of that scope.

(And before someone tells us that SMS 2FA is insecure I would like to point out that we use this for verification purposes in our booking system when a customer makes a booking. So for end-customers, not for users. It is a chosen strategy for making verification easy as alternatives are too complex for many consumers. All users however authenticate with email and password, and have the option of adding TOTP 2FA).

Customer: "But I had no problems when the code came to my phone."

"Unfortunately, many of our other customers, and customers of other financial institutions were not correctly protected by the code alone.. and were still getting scammed or confused.. and losing _all_ their money."

Customer: "[...] I'm finding this very frustrating, I need to get into my account."

"That is understandable, but we take the security of your account and your personal information very seriously, and this requires us to make changes to maintain that security in the face of new threats and actors as they evolve."

It’s all a gradual improvement over time though, as both companies are able to adopt better practices and customers become accustomed to it. Many, many more people are using TOPT than a decade ago.

it would be most convenient to have no 2FA. hell, skip the password too, then nobody will forget theirs. security is tradeoffs, but NIST says "if you take security seriously, you should not use SMS 2FA".

I don't see why SMS would need to write to a store, public or not. One can implement SMS-2FA using TOTP for example, it's just that the TOTP secret is not shared with the recipient.

What if my OTP base data is exported to a publically-readable datastore? I could be tricked into exporting the QR codes from Google Authenticator, for example. Though I see that there are significantly better 2FA methods, it does seem like the biggest flaws with SMS 2FA are in the insecure implementations, not the actual concept.

Thanks, this is the hint I needed.

Same with Natwest / Virgin. I do not think I have ever verified anything with SMS banking wise, sometimes you get alerts via SMS though.

But did you RTFA? SMS aggregators can also be hacked or can leak SMSs by accident.

Ban would need to be combined with a requirement for something else.

I think 999 of those databases are the same data set. I lost a password ten years ago from a blog breach and I get almost a monthly notification about it showing up again and again.

Good point.

But what's the threat model here?

I didn't think of 2FA as being protection against password reuse. People should still avoid reusing passwords and change them if they know of a breach.

Are there really attackers who are picking up breach databases and then sim-swapping to get the 2FA as well?

You cannot disable this anymore. You can add a hardware key, but cannot disable the mobile confirmation thing.

It is not but CCC is indicating that this provider was only used for 2FA. Sorry I was getting a bit ahead of myself here, this was earlier exposed as a breach of Twilio's vendor (IdentifyMobile). In the case of Twilio they offer an API for 2FA, Twilio Verify. I wanted to clarify that this breach was not only for 2FA, Verify API in the case of Twilio, but for all SMS sent through IdentifyMobile.