Blog post

When and Where Strong Authentication Fails (by Avivah Litan)

By Earl Perkins | November 25, 2009 | 0 Comments

Please welcome to the IAM Blog my colleague Avivah Litan. She is preparing a research note on the critical topic of when and where strong athentication fails and has provided a preview of that note below.

When and Where Strong Authentication Fails, by Avivah Litan

Criminals are successfully launching man-in-the-browser attacks that circumvent strong two factor authentication that executes through the user’s browser. The fraudsters are also successfully having telecommunication carriers forward phone calls used to authenticate users and/or transactions to the fraudster’s phone instead of the legitimate user’s phone. These attacks have been successfully and repeatedly executed against many banks and their customers across the globe in 2009. While bank accounts are the main immediate target, these attack methods will migrate to other sectors and applications that contain sensitive valuable information and data.

A layered fraud prevention approach that includes server-based fraud detection and out-of-band transaction verification that precludes call forwarding to illegitimate user phone numbers can and has mitigated these threats.

Here’s how some of the attacks have worked:

  • Malware sites inside a user’s browser and waits for the user to log into a bank. During the log-in, the malware copies the user’s credentials and one-time-password (OTP) number, sends them to the attacker and stops the browser from sending the login request to the bank’s website, telling the user the service is ‘temporarily unavailable.’ The fraudster then immediately uses the credentials and OTP number to log in and drain the user’s accounts. .
  • Other malware overwrites transactions sent by a user to the online banking website. This overwrite happens behind the scenes so that the user does not see the revised transaction values.
  • Similarly, in cases where the online bank sends specific transaction information back to the user to confirm, e.g. $10,000 being transferred to Account A, the malware overwrites the transaction values sent back to the bank after user confirmation, for example so that the $10,000 transfer goes to Account B.  The user only sees Account A on the transaction detail display so confirms the transfer by entering a one-time-password generated by a dedicated token, without knowing that malware will change Account A to Account B before the confirmation reaches the bank.
  • Authentication that depends on a user’s phone as a second factor is circumvented by a simple technique whereby the fraudster asks the phone carrier to forward the legitimate user’s phone calls to the fraudster’s phone. The fraudster simply tells the carrier the original phone number is having difficulty and needs the calls forwarded, and the carrier does not sufficiently vet the requestor’s identity before executing the fraudster’s request.


  • Recognize that any authentication method that passes through a browser can be defeated if the browser can be attacked and compromised.
  • Use server-based fraud detection to monitor transactions for suspect behavior.
  • Use out-of-band transaction verification to verify user transaction requests and only execute the specific transaction verified or signed by the requesting user.
  • Use out-of-band communication protocols that can prevent calls being forwarded to numbers that are not registered for a specific user account. 


Comments are closed