If you can "coach someone to ignore standard security warnings", you can coach them to give you the two-factor authentication codes, or any number of other approaches to phishing.

▲

harikb 6 hours ago | parent | next [-]

Installing an app that silently intercepts SMS/MMS data is a persistent technical compromise. Once the app is there, the attacker has ongoing access.

In contrast, convincing someone to read an OTP over the phone is a one-time manual bypass. To use your logic..

A insalled app - Like a hidden camera in a room.

Social engineering over phone - Like convincing someone to leave the door unlocked once.

▲

JoshTriplett 6 hours ago | parent | next [-]

> Installing an app that silently intercepts SMS/MMS data is a persistent technical compromise. Once the app is there, the attacker has ongoing access.

The motivating example as described involves "giving the scammer everything they need to drain the account". Once they've drained the account, they don't need ongoing access.

▲

jyoung8607 5 hours ago | parent | next [-]

Persistence allows the scammer free license to attempt password recoveries for every account the victim could possibly have. Other banks, retirement accounts, the victim's email account.

	▲	TeMPOraL 21 minutes ago \| parent [-]
		Scammer that thrive are greedy, but not too greedy. Easier to break into one type of account for 10 victims, than to break into 10 different account of one victim. Persistence is risk.

▲

sdenton4 5 hours ago | parent | prev [-]

When the victim's relatives send them money because they need to eat and pay rent after handing everything over to the scammer, the persistent backdoor lets that money be drained as well... You're underestimating the persistence and ruthlessness of the scammers.

▲

array_key_first 3 hours ago | parent | prev | next [-]

This is still not a root cause solution, it's just a mitigation. Because you do not require side loading to install malware. The play store and apple app store both contain malware, as well as apps which can be used for nefarious purposes, such as remote desktop.

A root cause solution is proper sandboxing. Google and apple will not do this, because they rely on applications have far too much access to make their money.

One of the fundamentals of security is that applications should use the minimum data and access they need to operate. Apple and Google break this with every piece of software they make. The disease is spreading from the inside out. Putting a shitty lotion on top won't fix this.

▲

TeMPOraL 14 minutes ago | parent | next [-]

> A root cause solution is proper sandboxing. Google and apple will not do this, because they rely on applications have far too much access to make their money.

Oh they do this quite well. Thing is, these sandboxes are meant to protect apps from you, not the other way around. That's why some apps - not just platform vendor apps but also select third-party apps - get special access and elevated privileges, while you can't even see what data they store in `/storage/emulated/0/android/data` even with ADB trickery.

▲

NewsaHackO 2 hours ago | parent | prev [-]

>The play store and apple app store both contain malware

Wow, that a major claim. What apps are malware, exactly?

>This is still not a root cause solution, it's just a mitigation.

Requiring signed apps solves the issue though, as it provides identification of whoever is running the scam and a method for remuneration or prosecution.

	▲	array_key_first 2 hours ago \| parent [-]
		> Wow, that a major claim. What apps are malware, exactly? I don't understand how this is a major claim at all, it should be obvious. All repositories of large enough sizes contain malware because malware doesn't declare itself as malware. This is exacerbated by the fact the Google Play Store and Apple App Store allow closed-source applications. It's much easier to validate behavior on things like the Debian repos, where maintainers can, and do, audit the source code. Google does not have a magic "is this malware" algorithm, that doesn't exist. They rely on heuristics and things like asking the authors "hey is this malware". As you can imagine, this isn't very effective. They don't even install and test the apps fully. Not that it matters much, obviously malware can easily change it's behavior to not be detectable from the end-user just running the app. > Requiring signed apps solves the issue though, as it provides identification of whoever is running the scam and a method for remuneration or prosecution. It doesn't, for three reasons: 1. Identifying an app doesn't magically make it not malware. I can tell you "hey I made this app" and you still have zero idea if it's malware. This is still a post mitigation. Meaning, if we somehow know an app is malware, we can find out who wrote it. It doesn't do the "is this malware" part of the mitigation, which is the most important part. 2. Bad actors typically have little allegiance to ethics, meaning they typically will not be honest about their identity. There are criminal organizations which operate in meatspace and fake their identities, which is 1000x harder than doing it online. Most malware will not have a legitimate identity tacked to it. 3. Bad actors typically come from countries which don't prosecute them as hard. So, even if you find out if something is malware, and then find out the actual people behind it, you typically can't prosecute them. Even large online services like the Silk Road lasted for a long time, and most likely still do exist, even despite the literal US federal government trying to stop them.

▲

hulitu 5 hours ago | parent | prev [-]

> Installing an app that silently intercepts SMS/MMS data is a persistent technical compromise.

Why would an app silently intercepts SMS/MMS data ? Why does an app needs network access ?

Running untrusted code in your browser is also "a persistent technical compromise" but nobody seems to care.

▲

nine_k 6 hours ago | parent | prev | next [-]

The 2-factor SMS messages usually say: "Do not give this code to anyone! The bank will NEVER ask you for this code!".

The sideloading warning is much much milder, something like "are you sure you want to install this?".

▲

JoshTriplett 6 hours ago | parent | next [-]

You'll then get more warnings if you want to give the sideloaded app additional permissions. And if they want to make the sideloading warnings more dire, that wouldn't be nearly as unreasonable.

▲

thefounder 6 hours ago | parent | prev | next [-]

the main issue is the bank using sms and OTP apps instead of something like passkeys and mandatory in bank setup.

▲

RobotToaster 4 hours ago | parent [-]

One of my banks uses a card reader and pin to log in, seems more secure.

	▲	microtonal 2 hours ago \| parent \| next [-]
		Pins can still be phished. Just make the phishing a live proxy resembling the real site. A fundamental difference with e.g. FIDO2 (especially hardware-backed) is that the private credentials are keyed to the relying party ID, so it's not possible for a phising site to intercept the challenge-response.
	▲	thefounder 44 minutes ago \| parent \| prev [-]
		That’s just as bad. You need to take out the human error out of the equation.

▲

hollow-moe 5 hours ago | parent | prev [-]

> The bank will NEVER ask you for this code!

> Please enter the code we sent you in the app.

lol, lmao even

▲

thousand_nights an hour ago | parent | prev | next [-]

yeah the thing is, if someone can social engineer you on the phone and make you do their bidding, you've lost no matter what

▲

mwwaters 4 hours ago | parent | prev | next [-]

The phisher’s app or login would be from a completely new device though.

Passkeys are also an active area to defeat phishing as long as the device is not compromised. To the extent there is attestation, passkeys also create very critical posts about locking down devices.

Given what I see in scams, I think too much is put on the user as it is. The anti-phishing training and such try to blame somebody downward in the hierarchy instead of fixing the systems. For example, spear-phishing scams of home down payments or business accounts work through banks in the US not tying account numbers to payee identity. The real issue is that the US payment system is utterly backward without confirmation of payee (I.e. giving the human readable actual name of recipient account in the banking app). For wire transfers or ACH Credit in the US, commercial customers are basically expected to play detective to make sure new account numbers are legit.

As I understand it, sideloading apps can overcome that payee legal name display in other countries. So the question for both sideloading and passkeys is if we want banks liable for correctly showing the actual payee for such transfers. To the extent they are liable, they will need to trust the app’s environment and the passkey.

▲

instagib 5 hours ago | parent | prev [-]

Never ending worm approach is to get remote control via methods on android or apple. Then scam other contacts. It’s built into FaceTime. Need 3rd party apps for android.