by Earl Perkins | November 25, 2009 | Comments Off on When and Where Strong Authentication Fails (by Avivah Litan)
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.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.