Author: Ng Wee Kai

Typical Pitfall in Two factor authentication Implementation

Financial industry has been deploying two-factor Authentication tokens to Internet customers. These tokens are small, self-contained devices capable of generating a short-lived / one-time password for a single use in an application (typically logon). The password is usually generated cryptographically from a personalized symmetric key shared with the bank – and is typically varied by means of a clock, counter value or user-input challenge (or combinations).

The introduction of the token introduces an additional layer of defence to attacker and provided additional safety to end user. However the effectiveness of the token is greatly dependent on the usage strategy.

The two-factor authentication fails if the attacker can launch a man-in-the-middle attack from his phishing site. In such an attack he will interfere with the login process by masquerading as a user to the bank and vice versa – thus providing the user’s input to the bank and proxy the bank’s response back to the user. The attack is illustrated in figure 1 below for a challenge-response scenario:

1. The user receives a phishing email with a link to the fake web site.
2. The user follows the link and is presented with a copy of the bank’s login screen, where he enters the user login information and the OTP generated by the token.
3. The fake server re-directs the information to the authentic bank web server.
4. The fake server verifies that the login is successful.
5. If the login information is correct, the fake server responses with a “Service temporary unavailable” message, so that the user will not do anything. However, at this point, the phisher will have the logon to the bank server and be able to perform actions as the user.

Clearly the MITM attack implementation requires the fake website to simulate as closely as possible to the real web site so that the user will not be suspicious. The level of depth an attacker is required to engage the user will determine the effort required to fake the site. The greater effort an attacker requires to fake the site will mean a more effective two factor implementation strategy.

Weak implementation Strategy

When the token authentication is requested only during the login process to authenticate the user, the attacker need only minimum effort to impersonate the user. This is because subsequence access to the functions does not require information from the token, hence no further engagement from the user is needed. The attacker could simply return a “Service temporary unavailable page” to the user, while he continues to impersonate the user.

Strong Implementation Strategy

However, if the token OTP authentication is prompted when accessing critical functions beside the login pages, the attacker needs to continuously engage the user after the login, increasing the effort needed to fake the site. If it is necessary for the user to see their account information, the attacker will need to additionally ensure those information are correctly sent and displayed to the user. This creates extra obstacle to the attacker, as he will need to have access to those pages so that he can implement the MITM server correctly. (For detail on possible changes he would need to make, please refer to here) Therefore, challenging the user at later times will increase the level of protection a two factor authentication can provide.

Many of the sites today which deploy two factor authentications does not implement such strategy, making MITM more likely to succeed. This is a classical example of the gap between software design and security design.