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…
> The site was an immaculate knock off ... Then I can picture a great way, locally, to screw these knock off big times. Either the site is a great knock off, visually similar (if not identical) or it won't fool people, right? So what about this: what about the browser saving, locally, screenshots of the login pages you visit. Then, when a new login is made, compare, visually, the page to what's saved and see if any s…
Second factor SMS: Worse than its reputation
191–200 of 323 posts
Re: Second factor SMS: Worse than its reputation
#192Earlier quoted context omitted.
They force SMS 2FA because it is a lot more frictionless to assume that your users have a phone number than to assume that they have a 2FA app installed on their phone and know how to manage those tools. It's also easier to support.
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.
Re: Second factor SMS: Worse than its reputation
#193A 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…
Just use apps. Apple protects.
Re: Second factor SMS: Worse than its reputation
#194Re: Second factor SMS: Worse than its reputation
#195Earlier quoted context omitted.
Hot take: rooted phones are inherently less secure. That does not include GrapheneOS btw, since you don't have root privileges on an official build of GrapheneOS.
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".
You're putting words in my mouth that I explicitly rejected when I said "that does not include GrapheneOS". Just to prevent the follow up "well actually GrapheneOS is an organization": they don't have any kind of root access to GrapheneOS phones. The only thing they can do is push system updates, which you can (1) reject and (2) verify if they are the same updates being pushed to all users, to avoid targeted attacks.
> Secure for whom? For the user? Seems obviously wrong. It's more secure for someone else to have power over you?
Yes, secure for the user. Sure, power users that very carefully review any system mods they install with root powers would have the same level of security as with a non-rooted phone. But most people won't read the source code of root apps/extensions they install.
It's easier to tempt mobile phone users to install "cosmetic improvement/customization whatevers" that happen to require elevated privileges, than desktop Linux users. It's well known that many Android apps bundle near-malware that slurps all data possible, and will ask for root privileges if that is detected.
The fact is that mobile phones tend to contain more sensitive data than desktop computers (and are thus significantly more secure by default than Linux/Windows computers). Contacts, private messages, photos, etc. It's a more valuable target, so more effort is put in developing malware for phones.
Re: Second factor SMS: Worse than its reputation
#196Unfortunately, for some other services, like banks or government agencies, you don’t have any option. You can only minimize the impact by using a unique password and username and keeping them updated.
Re: Second factor SMS: Worse than its reputation
#197Earlier quoted context omitted.
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...
Well, TIL
Re: Second factor SMS: Worse than its reputation
#198It described me the whole page, explaining it was a login page to log in to bank X in country Y. He compared the URL with the bank's name, etc.
Then I modified one letter in the URL, changing "https://online.banking.com" (just an example) to "https://online.banklng.com" and asked ChatGPT 4o again.
He said it was a phishing attempt.
So, basically, you can, today, already have a screenshot automatically analyzed and have a model tell you if it's seemingly legit or not.
Re: Second factor SMS: Worse than its reputation
#199Earlier quoted context omitted.
> The site was an immaculate knock off ... Then I can picture a great way, locally, to screw these knock off big times. Either the site is a great knock off, visually similar (if not identical) or it won't fool people, right? So what about this: what about the browser saving, locally, screenshots of the login pages you visit. Then, when a new login is made, compare, visually, the page to what's saved and see if any s…
Another step everyone will ignore because it isn't a problem for any particular person until it is.
Well then enforce it, at the browser level.
Re: Second factor SMS: Worse than its reputation
#200A 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…