Difference between revisions of "Testing Multiple Factors Authentication (OWASP-AT-009)"

Revision as of 12:34, 25 August 2008

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

This is a draft of a section of the new Testing Guide v3

Brief Summary

Evaluating the strength of a “Multiple Factors Authentication system” (MFAS) is a critical task for the Penetration tester. Banks and other Financial institutions are going to spend considerable amounts of money on expensive MFAS; therefore performing accurate tests before the adoption of a particular solution is absolutely suggested. In addition a further responsibility of the Penetration Testers is to acknowledge if the currently adopted MFAS is effectively able to defend the organization assets from the threats that generally drive the adoption of a MFAS.

Description of the Issue

Generally the aim of a two factor authentication system is to enhance the strength of the authentication process. This goal is achieved by checking an additional factor, or “something you have” as well as “something you know”, making sure that the user holds a hardware device of some kind in addition to the password. The hardware device provided to the user may be able to communicate directly and independently with the authentication infrastructure using an additional communication channel; this particular feature is something known as “separation of channels”.
Bruce Schneier in 2005 observed that some years ago “the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses” [1]. Actually the common threats that a MFAS in a Web environment should correctly address include:

1. Credential Theft (Phishing, Eavesdropping, MITM e.g. Banking from compromised network)
2. Weak Credentials (Credentials Password guessing and Password Bruteforcing attacks)
3. Session based attacks (Session Riding, Session Fixation)
4. Trojan and Malware attacks (Banking from compromised clients)
5. Password Reuse (Using the same password for different purposes or operations, e.g. different transactions)

The optimal solution should be able to address all the possible attacks related to the 5 categories above. Since the strength of an authentication solution is generally classified depending on how many “authentication factors” are checked when the user gets in touch with the computing system, the typical IT professional’s advise is: “If you are not happy with your current authentication solution, just add another authentication factor and it will be all right”. [2] Unfortunately, as we will see in the next paragraphs the risk associated to attacks performed by motivated attackers cannot be totally eliminated; in addition some MFAS solutions are more flexible and secure compared to the others.
Considering the 5-Threats (5T) above we could analyze the strength of a particular MFAS solution, since the solution may be able to Address (A), Mitigate (M) or Not Address (NA) that particular Web Attack.

Gray Box testing and example

A minimum amount of information about the authentication schema in use is necessary for testing the security of the MFAS solution in place. This is the main reason why has been omitted the “Black Box Testing” section. In particular a general knowledge about the whole authentication infrastructure is important because:

• MFAS solutions are principally implemented to authenticate disposal operations. Disposal actions are supposed to be performed in the inner parts of the secure website.
• Attacks carried out successfully against MFAS are performed with a high degree of control over what is happening. This statement is usually true because attackers can “grab” detailed information on a particular authentication infrastructure by harvesting any data they can intercept through Malware attacks. Assuming that an attacker must be a customer to know how the authentication of a banking website works it’s not always correct; the attackers just need to get control of a single customer to study the entire security infrastructure of a particular website (Authors of SilentBanker Trojan are known for continuously collecting information of visited websites while infected users browse the internet. Another example is the attack performed against the Swedish Nordea bank in 2005 [3])

The following examples are about a security evaluation of different MFAS, based upon the 5Threats model presented above.
The most common authentication solutions for Web applications is User ID and password authentication. In this case, it is often required an additional password for authorizing wire transfers. MFAS solution add “something you have” to the authentication process. This component is usually a:

• One-time password (OTP) generator token.
• Grid Card, Scratch Card and any information that only the legitimate user is supposed to have in his Wallet
• Crypto devices like USB tokens or smart cards, equipped with X.509 certificates.
• Randomly generated OTPs transmitted through a GSM SMS messages [SMSOTP] [4]

The following examples are about the testing and evaluation of different implementations of MFAS similar to the ones above. Penetration Testers should consider all possible weakness of the current solution to propose the correct Mitigating Factors, in case the infrastructure is already in place. A correct evaluation may also permit to choose the right MFAS for the infrastructure during a preliminary solution selection.
A Mitigating Factor is any addition component or countermeasure that might result in reduced likelihood of exploitation of a particular vulnerability. Credit cards are a perfect example. Notice how little attention is paid to cardholder authentication. Clerks barely check signatures. People use their cards over the phone and on the Internet, where the card's existence isn't even verified [5]. The credit card companies spend their security dollar “controlling” the transaction, not the cardholder. The transactions could be effectively controlled by behavioral algorithms that automatically fill up a risk score chart while the user uses his own credit card. Anything that is marked as suspected could be temporarily blocked by the circuit. Another Mitigating Factor is also informing the customer about what is happening through a separate and secure channel. Credit Card industry uses this method for informing the user about credit card transactions via SMS messages. If a fraudulent action is taken, the user knows immediately that something gone wrong with his credit card. Real time information through separate channels can also have an higher accuracy by informing the user about transactions, before those transactions are successfully.

Let’s analyze some different implementations of MFAS:

References

Whitepapers
...
Tools
...