Yesterday The Technology Review wrote an article entitled "Real-Time Hackers Foil Two-Factor Security" in which they posit the claim that "One-time passwords are vulnerable to new hacking techniques". This was an interesting article which several clients forwarded to us, asking what our thoughts are on the piece.
To be honest, it is easy to point fingers at the two-factor authentication (2FA) system here, but we would be looking for fault in the wrong place. The root cause of this attack is not in the authentication system, for the adversaries used a trusted communication channel to complete banking transactions AFTER the authentication of the user had already occurred.
This is a rather clever attack. An adversary waits in hiding with malware running unbeknownst to the victim on the victim's computer, which then uses a newly established session to conduct illegal banking transactions concurrently while the victim conducts their own transactions. The fault doesn't lie in the authentication of the user's identity during initial logon, but the validation of the session and its transactions as they occurred. Since the adversary had to conduct the illegal activity inside the session the user had established, it could be argued that it was up to the bank to ensure that transactions conducted were from the interactive session the user actually established with their current browser. Each transaction could have then be mutually authenticated and authorized as they occurred, significantly reducing this type of illegal activity by verifying the integrity of the transactions during the session.
Further to this, when monetary transactions of this type of volume occur (reports show over $447,000 was stolen during this attack across 27 transactions), an extra authentication with a new one-time password (OTP) may have been appropriate to authorize the approval of such large transactions. It may not make sense to prompt for another OTP to look at a bank statement or pay a bill, but it sure would make sense when moving tens of thousands of dollars in a single click. This is the whole point of risk-based authentication decisions, a common use of our own AuthAnvil Strong Authentication System web service APIs.
Of course, absolute security is a myth. With enough money and motive, any system can be breached. This attack is a perfect example of a tailored exploit to which only a very small number of users could ever be affected by. And to which the risk could have been drastically reduced had the user:
- Used a browser such as IE8 which provided segregated integrity levels to prevent malware from installing in the first place.
- Used InPrivate Browsingwithin IE8 to reduce the artifacting of session data on the local system.
- Deployed antivirus and antimalware countermeasures to isolate, quarantine and clean the system, helping to maintain the integrity of the system.
- Considered using isolated systems for the soul purpose of conducting high-risk transactions if they plan to allow for transfers of that sort of money to begin with.
So in summary, this was NOT a foiling of the two-factor authentication system that the bank used. It would not have mattered if this bank used a single factor, multi-factor or even a mutual authentication mechanism during logon. The adversary would still have been able to conduct this attack. The failure occurred in how the transactions themselves were handled, which is more a defect in the coding of the system, and the lack of integrity in the user's system used to complete the online transaction in the first place. In other words, there is a lot of blame to go around. And little of it should be pointing to the 2FA system.
I hope that addresses the questions several of you have had about this incident. Although AuthAnvil was not the solution used at this bank, I think it is only right to make clear that the failing isn't in one of our competitor's authentication systems. It was in the design and architecture of the web based system that allowed an out of band stream of data from the malware in question to conduct illegal transactions.
If you would like to continue this conversation, please leave a comment. If you would like to explore how your team could write secure code to take advantage of risk-based authentication decisions using the AuthAnvil Web Services API, let's talk. We would welcome the opportunity to explore this with you!
Comments