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

6 points

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

permalink
report
reply
3 points
*

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)

permalink
report
reply
3 points

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

permalink
report
parent
reply
1 point
*

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.

permalink
report
parent
reply
19 points

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.

permalink
report
reply
8 points

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.

permalink
report
parent
reply
3 points

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).

permalink
report
parent
reply
4 points

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.

permalink
report
parent
reply
5 points

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.

permalink
report
parent
reply
1 point
*

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.

permalink
report
reply
6 points

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).

permalink
report
reply

Cybersecurity

!cybersecurity@fedia.io

Create post

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

Rules

Community Rules

  • Be kind
  • Limit promotional activities
  • Non-cybersecurity posts should be redirected to other communities within infosec.pub.

Community stats

  • 863

    Monthly active users

  • 63

    Posts

  • 173

    Comments