92

So, why do almost all banks, in the U.S. at least, only support the worst 2FA authentication method exclusively? And, this article doesn't mention SIM-swap attacks, which are unavoidable. It can't be that difficult to support an authenticator app.

https://gizmodo.com/feds-warn-sms-authentication-is-unsafe-after-worst-hack-in-our-nations-history-2000541129

#Cybersecurity

top 19 comments
sorted by: hot top controversial new old
[-] ChiefSinner@lemm.ee 1 points 10 hours ago* (last edited 10 hours ago)

I think there's lots of reasons. I may or may not have work/worked for a bank. Typically, they use HSA's tied to large range systems like z/OS that generate the seed. The seeds themselves are secure and are not really prone to time attacks like authenticator apps/soft tokens sometimes are.

Its a stupid trade off tbh. However, I think its less likely for people to call in frantic because they can't get into their bank account because everyone are more likely to retain access to their phone and/or email than for the bank to support a 3rd party authenticator app that may or may not be backed up from another 3rd party software.

Also, over time, the authenticator apps can get off sync by a few seconds. That's why its typically offset by 30 seconds when you set it up on most sites, which lessens the likelihood of it getting too off sync for it to work. However, it widens the gaps for time based attacks to bypass 2fa altogether. RSA Securid, I believe, is only like 3 seconds by default but don't quote me on that. That's why you gotta replace the hard tokens for those every 60 months. The battery in them slows down the clock and it gets out of sync.

I could be wrong, but i believe every time you shut your phone off, technically, gets your soft tokens out of sync ever so slightly too. I once had an authenticator app on a phone where the battery died or something that prevented me from turning it back on. It took like a month or two before I could get back in it. By the time I did, none of the soft tokens worked anymore because it became offset by more than 30 seconds.

[-] Fiivemacs@lemmy.ca 23 points 1 day ago

I've filed about 7 complaints to the Ombudsman where I live for my bank. I refuse to use sms for verification. I blame the bank for limiting my access to my accounts as a result. I've spoken to hundreds of employees, for hours and hours, wasted in branch time for hours, spoken with managers, escalated numerous tickets.

I've probably wasted more of their time and money, then it would have been for them to just implement 2fa from an app rather than sms..

I've proven to them how insecure it is. Employees and managers tell me I'm paranoid for nothing.

I'm so sick of this fight with them. Literally have no idea what else to do other then constantly complain, open tickets hourly and literally waste their time, ruin their metrics and annoy the hell out of anyone that works at the bank. I won't use sms for 2fa.

[-] kipo@lemm.ee 3 points 1 day ago
[-] Fiivemacs@lemmy.ca 2 points 15 hours ago

Literally got a call today from the ombudsman and had to explain it to them. It was like talking to politicians about the internet.

I'm hoping they can at least implement something better then sms.

[-] DahGangalang@infosec.pub 19 points 1 day ago

I bet its the cheapest and/or easiest to implement. Why do more than the bare minimum, amirite?

^I feel like mine is a bad faith opinion, but I also feel passionately about this and want to ensure your post is getting some level of engagement so it can maybe get some proper discussion going.

[-] pivot_root@lemmy.world 8 points 1 day ago

A cynical thought: what if it's actually less risky to make 2FA someone else's fault when it fails, rather than worry about ever having to be held accountable for an insecure implementation they created.

[-] DahGangalang@infosec.pub 3 points 1 day ago

Thats a good point.

I expect the courts would uphold that flavor of argument too (at least in the U.S.; I expect the same in other countries, but don't feel comfortable speaking for systems I'm not at all familiar with).

[-] ricecake@sh.itjust.works 5 points 1 day ago

I mean, you're not wrong, just a hair off. It's the most universally possible to implement.

Every version of every phone can support SMS, and no one worries that someone is spying on them when they get one.

SMS is a terrible solution, but it's extremely easy to implement, and very accepted by people at large. That makes it all those things you mentioned, but it's backed by a very legitimate motivation.

In other contexts this explains part of the popularity of federated signin systems, since users may not trust you, but they probably trust their email provider, and if you can piggyback off their MFA, you don't have to hope the user will find you special enough to do the extra work.

Dedicated phone apps have a similar advantage, since you can leverage the phones built-in identity management.

Passkeys are currently being pushed very hard by security folks because, if done right, you can make the user more secure while making their sign-in process simpler, and letting them need to remember less and not install or manage anything.

You still have the ultimate issue of the atypical user who is valid and can authenticate, but for whatever reason has decided to only posess the dumbest of dumb phones, and can only accept SMS or phone calls.

[-] subtext@lemmy.world 4 points 1 day ago

I would wonder if they have done the cost / benefit of having to have support staff to help boomers who can’t use a TOTP app vs the cost of covering losses from SIM-swapping attacks. It’s probably a significant amount of money to hire all the people needed to support every grandma who can’t figure out where the six numbers come from.

[-] JSCybersec@infosec.exchange 3 points 1 day ago

@Jerry@hear-me.social Honestly, it's a "reach" reason. most people have a phone capable of receiving texts or a voice message (An actual call). Not everyone has a smartphone (or the technical chops to get a legitimate OTP app and setup TOTP). Is that an excuse to NOT offer TOTP or other better MFA options? No it isn't, but then they probably decided to not pay the extra 10c per user for the additional auth option. Cost/benefit analysis, with security not even being a part. If you want your banks to support more robust auth, hound the financial regulators to start making it a requirement.

[-] Mr_Blott@feddit.uk 6 points 1 day ago

Oh come on, the US is usually two decades behind modern banking, 2FA over SMS is only a decade behind, so it's an improvement!

You'll have 2FA via an app like the rest of us, but in 2034

Now run along and enjoy your chip and pin

[-] wesker@lemmy.sdf.org 9 points 1 day ago* (last edited 1 day ago)

My CU offers auth app support. Yet my big name options provider doesn't. It's so stupid.

[-] DahGangalang@infosec.pub 2 points 1 day ago

Similar on my end.

The main CU I work with will let you verify logons inside their mobile app when logging on from like a desktop (text/call only for mobile logins), but the high yield savings I have at a much larger name bank is text only for 2FA (Which is not a mandatory nor default setting BTW).

What's everyone's opinions on verifying logins via mobile apps?

[-] Fiivemacs@lemmy.ca 3 points 1 day ago

Anything but it being STUCK on my phone. Lose your phone and you're up shits creek. Reading through my banks info crap about their 2sv, every 2nd paragraph about any issue involves deactivating 2fa, and resetting it all up again.

It's being stupid. I want 2fs through an authenticator which I have locked down with another authenticator. I also have yubikey for quicker access for certain things.

[-] seathru@lemmy.sdf.org 1 points 1 day ago

I love my CU, but their app is an afterthought that tries (unsuccessfully) to use google authenticator. And if you try to call for tech support, you get whatever teller was unlucky enough to answer the phone.

Bless their hearts; they're trying. And I'd rather give them my business than any for-profit bank.

[-] BearOfaTime@lemm.ee 6 points 1 day ago

As much as I despise SMS in general, and 2FA over SMS in particular, I think the risk of SIM jacking in the US is pretty low overall for this use-case, which is probably part of why banks don't do more.

Add in (as others have said) the cost of proper 2FA and being able to off-load the risk (which is what banks do), and a VP of Risk Management doesn't have much motivation to drive such a change.

My own anecdotal experience with Sim-jacking and 2FA: I recently ported a number to a new service, properly, with multiple steps to verify I was authorizing the port. It broke every SMS 2FA - I had to login to every account and re-enter the same phone number as my 2FA number. Which required verifying my login with email or another number (that was already in the account).

[-] jatone@lemmy.dbzer0.com 3 points 1 day ago* (last edited 1 day ago)

because its also the most convenient and people are stupid and incapable of handling authenticator apps. plus auth apps are a maintenance burden between phone switching. overall 2fa was a poorly thought out concept to begin with from a end user perspective.

honestly the whole concept of modern 2FA is retarded when you can essentially get the same thing from ssh keys with passwords. (👋 @ passkeys which as basically that renamed)

[-] otp@sh.itjust.works 3 points 1 day ago

I understand SSH keys with passwords, but I don't understand passkeys yet because most of what I've read has been layman explanations of them.

Since you made the comparison, could you explain what passkeys actually are, or point me to a decent source that'll explain it not like I'm 5? Lol

[-] jatone@lemmy.dbzer0.com 1 points 16 hours ago* (last edited 16 hours ago)

SSH keys are a public and private keys that you can use to sign and verify messages back and forth. passkeys are literally the same thing. the only difference is passkeys are unique per site and you store them in an encrypted file that you only need a single password to access vs an ssh key the passwords are per key pair.

essentially the passkey is used to sign a bit of metadata and then the service verifies that metadata matches the user via the public key on file in their system. but otherwise they're functionally the same thing as ssh keys.

this post was submitted on 20 Dec 2024
92 points (100.0% liked)

Cybersecurity

2 readers
47 users here now

An umbrella community for all things cybersecurity / infosec. News, research, questions, are all welcome!

Rules

Community Rules

founded 2 years ago
MODERATORS