Most people think of authentication as validating the identity of the user for a session. While that is certainly accurate, in today's world of sophisticated attacks, Web application developers and security experts need to consider strengthening other authentication processes as well.
In this article we consider three authentication processes in a typical complex Web application that requires security, such as online banking or brokerage transactions:
Let's first look at the types of authentication attacks that can occur. They can be broken down into two major categories: man-in-the-middle attacks and malware attacks.
The vast majority of attacks are man-in-the-middle attacks. Phishing e-mails are calls to action to get users to visit fake man-in-the-middle Web sites. DNS-cache poisoning is an attack on a DNS server somewhere between the user's computer and the server that misdirects users to a fraudulent Web site.
There are two main types of authentication malware: keystroke loggers and session hijackers. A keystroke logger is malicious software that captures and forwards private information such as IDs, passwords, account numbers and PINs back to the author for later use. Many activate only when a user types in specific information, such as an online bank or brokerage URL. A session hijacker is malware that runs inside an SSL session and performs nefarious transactions, such as transferring cash out of an account.
How to protect customers
So, the bad guys have a slew of tools. How can companies protect their customers through stronger authentication?
Strong session authentication is a base requirement for securing financial Web applications. Session authentication must include use of time-bound, one-time passcodes. Non-time-bound passcodes have already been attacked by phishers, and in one case forced a European bank offline for 12 hours. Man-in-the-middle attacks can also be automated to a hig
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
h degree. For example, a fraudulent site could accept a time-bound one-time passcode and immediately use it to log in to the account within the time allowed. Only strong mutual authentication can stop man-in-the-middle attacks.
Mutual authentication is really site authentication to the user combined with user authentication to the site. Site authentication is technically provided by SSL. Unfortunately, many sites ask users to log in to non-SSL sites, and users rarely check SSL certificates for validity. Fraudulent Web sites 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 or some other form of non-cryptographic information as a shared secret to identify a server before a user enters his password. One possible attack against this is that a man in the middle 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 backup, then all the man in the middle 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 a one-time pad (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 it 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 an online account. For that reason, transaction authentication is recommended. Transaction authentication is different from digitally signing a transaction. It can be accomplished with a one-time passcode, making it much easier to implement. For example, when a user wishes to make a suspicious transaction, such as a one-time, large payment to a new payee, he should enter a second one-time passcode to validate the transaction.
Transaction authentication is particularly good for applications that have infrequent or irregular transactions, such as brokerage accounts. A lack of transaction history makes it hard to spot fraudulent activity via account monitoring. It is easy to spot fraudulent credit card activity, but it is difficult to know if every stock is being sold to buy a house or to line the pockets of an attacker.
It is critical that the transaction 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, a user might have a session token on his PC and a transaction token on his cell phone, greatly increasing security.
How would all this look from the user's perspective? The user logs in to his financial services account with a time-bound one-time passcode. The site is identified in a cryptographically strong method that is easily understood by the user. When the user wishes to make a risky transaction, he would be prompted again for a unique transaction-authorizing passcode. It is a consistent, secure process of authentication that minimizes potential avenues of attack, especially attack vectors beyond the control of either the user or the service provider. Falling back to additional questions or shared secrets only creates attack vectors.
Fraud and identity theft are frequently the result of weak authentication. Although the complete mitigation of risk is unrealistic, companies can maintain the integrity of applications with stronger authentication. By employing session, mutual and transaction authentication tools on the front-end, security can be significantly improved. Fraud can be reduced to a level where it does not impact the average user and can be covered by insurance.
---------------------------------
About the author: Nick Owen is CEO and co-founder of WiKID Systems Inc., developer of the commercial open source WiKID Strong Authentication System. You may reach him via e-mail at nowen@wikidsystems.com
