This didn't exist 10 years ago as a github project for anyone to download. How is it from a century in the distant past?
Also, email and phone numbers are LITERALLY standard methods of 2FA. So what are you expecting bank employees to use?
Also, email and phone numbers are LITERALLY standard methods of 2FA. So what are you expecting bank employees to use?
Someone who claims they are using 2FA, but actually authenticates with email and/or phone numbers, is committing fraud.
Even if, for example, a phone number were something you physically possessed, authenticating with only the phone number, or with the phone number plus any number of additional physical possessions, wouldn't be 2FA, because you're still only using one factor: "something you have".
Historically, voice-based biometrics were a valid form of biometrics, even without a trusted path: you could prompt someone to say something they hadn't said before so that an attacker couldn't play back a recording. That is no longer the case. As https://news.ycombinator.com/item?id=29712024 pointed out, Tacotron made this a plausible threat already in 02018.
What do I expect bank employees to use? Well, starting 34 years ago in 01987, classified voice communications used a STU-III, which authenticates both parties with public key certificates. PGP made that level of security available to everybody 30 years ago in 01991; Git uses it to sign tags, and Debian uses it to sign packages since 02005: https://wiki.debian.org/SecureApt. Every HTTPS website uses something similar, though browsers routinely trust untrustworthy CAs, which vitiates the security of the scheme.
While we can't expect bank employees to be as technically sophisticated as Debian volunteers, I do think it's reasonable to expect them to be less than 15 years behind, particularly when tens of millions of dollars are at stake. I don't believe that this will actually happen with the existing banking institutions; instead, I believe that they will fail and demand bailouts, which will just expand the scope of the disaster.
OK. I'll send you the list of all the companies that have done 2FA with me via email or a telephone number, and you can hit them up for fraud. Good luck! /s
The fact that some people get away with telling a lie isn't generally a very strong argument that it's not a lie.
People who use sarcasm tend to be very proud of it, but the aggressive-defensive undertone hinders productive conversations.
If there exists e.g. a bank which accepts printed credit tokens, and a technology comes to exist that allows for simplified forgery of those printouts, the bank must actively inform itself and act accordingly. The service provider must know "they are not in the century before Gutenberg, those centuries are past" (figuratively: the idea is about the press, not the movable type). If a service provider accepted instructions through postcards, they must know about the ease of forging signatures. If electronic postcards come to exist (they do: it's the E-Mail), all involved parts must know that postcards have no sender authentication, and act accordingly.
That someone seem to have access to John's telephone, it corroborates that such someone is John, it does not prove it. If someone seems to be John and also has access to John's telephone, that increases the chances that it is John. If only the access to John's telephone is there, it is far from granted that that is John. If an employee asks you for two documents, that is increased security; if the process becomes that "now an alternative document suffices", that is decreased security.
The employee is supposed first of all to be reliable, which means careful as opposed to lax. In the context of banking, the employee must be aware of lack of sender authentication in emails, of SIM swapping, and yes even of the possibility of "deepfakes" - the same way a hired shepherd should be aware of wolves, it's the job.
Its organization must enforce decent, commonsensical security - not "good sense" but really "common sense", because it would be unacceptable that the typical (unfortunately) faults one sees would not be evident as faults to a majority, when exposed. I have seen web-based services stipulated in their form through a preliminary contract which enables them (they could be limited according to the security the client wanted), and then modifiable in the user's control panel - you may request by contract a read only access - for reporting instead of operation -, and then once in front of the user interface one is two clicks away from granting the user full access. Everyone went facepalm when shown that, everyone but the "carefully" selected "soldiers" of the enterprise.