This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

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

From OWASP
Jump to: navigation, search
(Description of the Issue)
(Black Box testing and example)
Line 26: Line 26:
 
<br>
 
<br>
  
== Black Box testing and example ==
+
 
'''Testing for Topic X vulnerabilities:''' <br>
+
 
...<br>
 
'''Result Expected:'''<br>
 
...<br><br>
 
 
== Gray Box testing and example ==  
 
== Gray Box testing and example ==  
 
'''Testing for Topic X vulnerabilities:'''<br>
 
'''Testing for Topic X vulnerabilities:'''<br>

Revision as of 12:28, 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 (E) or Not Address (NA) that particular Web Attack.


Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...