Currently at a bank's security team, here's what I gathered so far that explains (but doesn't excuse) the current state of affairs:

- there are millions of customers who hate having to use their brains (or get their phone to receive a 2FA code);

- a kilometer of requirements from whatever Central Bank, local policies and ad-hoc decisions;

- (too) limited budget to build and run whatever service (cost of SMS 2FA for millions .vs. cost of some limited fraud);

- very, very bad dev education, and general disdain for security. We do have a guide for them (the "secure development handbook"), and all our code audits reveal that it wasn't followed in all places;

- outdated perception of security issues (screengrabbers are still a threat to tackle, according to some).

I guess it depends on the country and the bank. My bank, for example, does mandatory 2FA for 15+ years and uses some anomaly based approach to decide how aggressively to ask for 2FA, like if you send money somewhere unusual, it does phone call 2FA, instead of an SMS, and if you just pay your usual bills from the same IP address and the same PC it doesn't even ask for 2FA at all. It also has other optional security features like white lists for IP subnets, internet-only credit cards, etc.

That sounds terrible. I mean, I assume they don't assume liability for bad decisions?

If "the PC" or "the IP address" was not contractually agreed to be an authentication factor (that you thus should protect from unauthorized use), it's a terrible idea to use them for authentication, while also (presumably) putting all liability on the customer.

In France, and I believe it is the case in many countries, in case the customer wants to roll back a transaction, the bank has to give the money back, unless it can prove that the transaction was legitimate.

So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN.

Banks have to maintain a balance between convenience and risk of fraud.

> unless it can prove that the transaction was legitimate.

And what is the standard of evidence for that?

> So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN.

That doesn't sound like a second factor? Or are you talking about POS transactions?

> Banks have to maintain a balance between convenience and risk of fraud.

Really, they don't. The bank should never decide to take on risks for me. There is nothing wrong with offering a feature where the customer can select to allow certain transactions without 2FA. There is everything wrong with forcing that feature on customers.

Why would that be a terrible idea? If someone has unauthorized access to my PC and knows my password from the account, he can log in and pay my bills and only the usual amounts, as paying too much would trigger 2FA.

Because there is a risk associated with it that you didn't agree to.

I'm fiercly in favor of 2FA, and with DSP2[0] coming soon(TM), I have been pushing for sane 2FA at my place, in some select projects where it can be done with as little friction as possible.

I'm very interested in your bank and how they do it, I'll see if voice 2FA is something feasible at my place. Could you share the bank's name though? Management likes to have solid evidence that someone else is already doing it when the security team proposes "weird solutions".

[0] https://ec.europa.eu/info/law/payment-services-psd-2-directi... , https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32...

> screengrabbers are still a threat to tackle, according to some

I might be one of those "some". Why do you say that screengrabbers are not a threat to consider? There are hundreds of cases that I can think of where they can be a security issue.

Thank you for sharing an inside view!

This is unintentionally hilarious.

The most confusing thing is that a lot of banks (paypal included) still don't let you use "special chars" in your password. Or they will allow it but only for a very limited set that they don't tell you.

That's not true about Paypal though: "Use lower case, upper case, a number, and a special character [like ~!@#$%^&*()_+=?><.,/]." [0]

And even if the character subset is quite small (26 lower case, 26 upper case, 10 digits), it's still good enough if it's completely random and never leaked once. Just max out the password length (start at 32 char) and back track from there.

[0] https://www.paypal.com/us/smarthelp/article/Tips-for-creatin...

I find this to be a recurring theme when banking security comes up. Every time I've ever been in a position to check, the specific claims made by HN comments about lackluster bank security practices have not been true. I assume they must have been true at one point, but commenters don't check that they are still true before commenting.

It was true in 2016 when I created my account. it was also true about BoA, they allowed a limited char-set.

That doc isn't dated, but it was true as recently as three years ago.

This one seems almost sensible to me. They probably have some ridiculous 1960s-era mainframe on the backend and it’s cheaper to keep it running than to redo it all.

It's more likely that the code and whatever was used for the DB dates from the 1960s-70s (likely a mixture of COBOL, JCL, and who knows what else), and has fixed-width columns for the data fields, with the password configured to something small.

I'd say most if not all of this code is probably running on some IBM mainframe from the 1980s or 90s - possibly later - and likely in some kind of emulation or backwards compatibility mode (so something from the 80s/90s would likely allow for running S/360 stuff, and so forth).

The actual hardware, though, has either been scrapped or is in a museum somewhere. There are very, very few instances of organizations still running "ancient" hardware (though the few that are tend to be known by the mainframe collecting community from what I understand).

I was super impressed to find that PayPal supports TOTP now, as the the brokerage Robinhood. Everyone else is still doing proprietary tokens, sms, or good looks for MFA. Tumblr had TOTP first but go PayPal, they get a pat on the back for doing something right.