Financial institutions should strive to provide their customers with a consistent, secure process of authentication that minimizes potential avenues of attack, especially attack vectors beyond the control of either the user or the bank.
Understanding the types of attacks that can occur is a requirement for deciding what authentication mechanisms are needed. There are two main attack vectors discussed: man-in-the-middle attacks and malware.
The vast majority of attacks are Man-In-The-Middle (MITM) attacks. Phishing is email calls-to action to get users to fake MITM websites. DNS-cache poisoning attacks a DNS server somewhere between the user's computer and the server to misdirect users to a fraudulent website.
Malware is malicious software that captures and forwards private information such as ID's, passwords, account numbers, and PINs. Keystroke loggers log keystrokes and send them back to the author for later use. Many activate only when a user types in specific information, such as a bank site URL. Time-bound, one-time passcodes thwart keystroke loggers, as they would be used or expired before the attacker gets them.
Session-hijackers run inside an SSL session and perform nefarious transactions. Session-hijackers are particularly tricky in that they work after session and mutual authentication have been complete. They are why many pundits have suggested that two-factor authentication won't stop online fraud. These pundits miss an important point: that the server can ask for a second one-time passcode to validate the transaction. It is key, however, that the transactional authentication method be distinct from the session authentication method or the attacker will just generate a "Connection Lost" error message, prompt the user to log in again and use that OTP for the fraudulent transaction.
An important question to answer in determining what type of authentication to use is: What exactly are you wanting to authenticate? Most people think of authentication as validating the identity of the user for a session. We add to that: session authentication is validating the user to the site; mutual authentication adds validation of the site to the user; and transactional authentication is validating that it is the correct user requesting the transaction.
Strong session authentication is a base requirement for securing online banking. Session authentication must include some time-bound, one-time use passcodes. MITM attacks can be automated to a high degree. For example, a fraudulent site could accept a time-bound one-time passcode and immediately use it to log into the bank within the time allowed. Only strong mutual authentication can stop MITM attacks.
Mutual authentication is really site authentication to the user combined with user authentication to the site. Site authentication is already provided by SSL. Unfortunately, many sites ask users to log into non-SSL sites and users rarely check SSL certificates for validity. Fraudulent websites can use self-issued SSL certificates to fool users or generate a fake SSL 'key lock' and position it over the key location in the browser. SSL site authentication is clearly broken.
Some have suggested using unique images as a shared secret to identify a server before the user enters their password. One possible attack against this is that a MITM could replay the initial request and any additional information from the user's computer to the server and in turn provide the user with the image. Also, if the mutual authentication method uses machine authentication as a primary mechanism and knowledge authentication as a back up, then all the MITM has to do is present the user with the questions asked by the site. Since there is a lack of consistency in the session authentication method, the mutual authentication method becomes suspect.
Another method, as developed by WiKID Systems, uses a hash of the server certificate stored on the authentication server. When the user requests an OTP, the hash is also sent to the token client. Before presenting the user with the OTP, the token client fetches the certificate from the web site, hashes it and compares it to the retrieved hash. If the hashes match, the URL is presented as validated and the default browser is launched to that URL. This method leverages the security and investment in SSL certificates and provides a consistent session and mutual authentication method to the user.
Even with both session and mutual authentication methods strengthened, a session hijacking trojan could empty a bank account. For this reason, transaction authentication is recommended. Transactional authentication is equivalent to digitally signing a transaction and it can be accomplished with an OTP. For example, when a user wishes to make a suspicious transaction, such as a one-time, large payment to a new payee, they should enter a second one-time passcode to validate the transaction. It is important, as mentioned previously, that the transactional authentication be cryptographically distinct from the session authentication mechanism or the attacker will try to get the user to re-authenticate for the session. This requirement highlights a key difference between shared-secret systems and public-key systems. A public key system can support multiple authentication servers with no reduction in security. One public key pair can be for sessions and another for transactions or a user could have more than one key pair on separate devices. For example, they might have a session token on their PC and a transaction token on their cell phone.
Account fraud and identity theft are frequently the result of weak authentication. Although the complete mitigation of risk is unrealistic, financial institutions can effectively maintain the integrity of online banking with stronger authentication. The key threats are MITM attacks, keystroke loggers and session hijackers. By employing session, mutual and transactional authentication tools on the front-end, web application security can be significantly improved. Using back-end fraud detection mechanisms to detect potentially fraudulent transactions that might slip through the front-end can further reduce fraud. There is no reason why online banking cannot be as secure as credit card transactions. Fraud can be reduced to a level where it does not impact the average user and can be covered by insurance.
- Nick Owen is the Founder and Chief Executive Officer of WiKID Systems, Inc. www.wikidsystems.com