Many companies (ranging from commercial to multimedia and financial sectors) have moved or are moving their services to the Internet, including critical processes such as payments. As a result, the issue of ensuring the identity of the accessing counterpart becomes critical.
Multifactor authentication (also widely known as strong authentication) has gained general consensus in the IT field as a fitting solution for such critical services. However, taking a closer look, this is true only if the basic concept is fully understood and the implementation details are designed accordingly.
This article focuses on the security of the authentication procedure set up by a service provider (SP) using a solution/tool obtained by a technical security provider (TSP). The Internet user (IU) uses the solution to access an online service by means of a personal access device (AD) equipped with a web browser (e.g., PC, smartphone, tablet). This article aims to provide organizations that are planning to introduce a strong authentication procedure with useful guidelines and warnings in view of achieving a higher level of protection.
According to current best practices and standards (e.g., ISO 27002 and COBIT 5), adequate information security can be ensured only via a holistic approach, i.e., through a risk analysis, considering all available protection measures (including nontechnical ones) with respect to all relevant threats. However, it can be recognized that among all security measures applicable to the provision of Internet services, the authentication procedure plays a fundamental role in mitigating the insidious risk of identity theft by cyberintruders and fraudsters.
Strong authentication is generally defined1 as an authentication procedure requiring the combination of multiple authentication factors,2 including at least two of the following:
The rationale is that the combination of factors, which are different in nature, prevents the chance that a single vulnerability in the technical solution could undermine the security of the whole authentication procedure allowing intruders to impersonate legitimate users (i.e., identity theft). It can be viewed as a specification of the security principle, borrowed from military strategy, of defense-in-depth, in which the breach of one defense line is caught by the second line. This implies the following considerations:
It is worth highlighting that the aforementioned requirement of having mutually independent factors could be difficult to match. In fact, in the context of access to Internet services, when using ownership and inherence factors as well as when inputting a PIN or password, the user transmits digital data to the verifying counterpart (i.e., authentication codes), so that regardless of the generating factor, susceptibility to interception is a common vulnerability.
As a consequence of the aforementioned considerations, an organization should seek a solution that entails:
The latter principle can be translated to the relevant quality characteristics to be applied. In figure 1, these key characteristics are listed indicating the relevant authentication factors (knowledge, ownership and inherence—referenced as K, O and I respectively) applicable to each one of them, together with explanatory notes as needed.
In addition to the characteristics listed in figure 1, whenever secrets that can be helpful in guessing passwords are stored, adequate systems and procedures should be in place for their treatment. In particular, it is recommended not to store reusable authentication codes (e.g., passwords) in the SP’s systems unless they are properly encrypted.3
In regard to the ownership factors with, for example, token-generating one-time passwords (OTPs), it is advisable to evaluate solutions not involving the storage of secret codes at the TSP’s premises.
In addition to the discussed properties of quality and independence of the authentication factors, other controls need to be adopted, including factor management (e.g., tool initialization, provisioning, renewal procedures) and account management (e.g., retry limits, unblocking procedures) for which reference can be made to suitable standards/ frameworks (e.g., ISO 27002, COBIT).
Having outlined the fundamental requirements of a strong authentication solution, this article will now discuss common cases of implementation to determine whether they meet the standards for strong authentication. In some cases, the article highlights (see items one to four of the following list) implementation mismatches with respect to the proposed independence and quality characteristics. In other cases (see items five and six), there are some possible vulnerabilities to be taken into account. The following list does not include the use of inherence factors since they are not widespread allegedly due to drawbacks and other inconveniences4:
To explain why sending just an OTP as the authentication code could be risky, a significant example that can be considered a variation of the classic brute-force attack is discussed hereafter. In this example, an SP adopts a solution like those mentioned in number three or four in the previous list, making use of a six-digit OTP and allowing up to three consecutive incorrect attempts before blocking the account. An attacker knowing the username or ID of a customer (which generally is not confidential) and using a fixed number of six chosen digits—assuming that at least one successful access is made by the average legitimate user in a week—may try to enter the relevant account only three times per week. In one year, the attacker’s chances of success can be calculated using the formula in figure 26 (with K = 3 x 52 = 156; N = 1,000,000), having assumed that the algorithm is sound and the generated numbers appear evenly random, is about one out of ten thousand (1/10,000).
While that does not seem alarming, it can be calculated that for a massive similar attack targeted to a big SP, the probability of success increases dramatically. For example, in a case in which the attacker knows the user ID of some 300,000 customers (e.g., by knowing the algorithm the SP has adopted to generate them), with only three tries on them all (executed by means of an automated tool), the likelihood of entering at least one of the accounts (putting K = 3 x 300,000) is nearly 60 percent.7 Therefore, unless longer OTPs and/or other compensative measures are implemented, such a solution cannot be trusted; moreover, this example shows that a whole group of user IDs (and their formulation) should not be made publicly available.
Multifactor authentication can be deemed strong only if the choice of the technical solution and its implementation are achieved in light of sound principles and criteria, including the substantiated independence of the selected authentication factors. The stronger security of solutions not properly taking into account these requirements is questionable.
The author wishes to thank Pietro Franchini and Ravenio Parrini for their review of this article and their feedback.
The views expressed in this article are those of the author and are not necessarily those of Banca d’Italia.
1 In spite of extensive use in the IT security sector, the notion of strong authentication has not been standardized yet in the security literature. For a basic definition, see Federal Financial Institutions Examination Council (FFIEC), “Authentication in an Internet Banking Environment,” and “FAQ,” 12 October, 2005 and 15 August, 2006.2 Federal Financial Institutions Examination Council (FFIEC), “An authentication factor (e.g., PIN or password) is secret or unique information linked to a specific customer identifier that is used to verify that identity.”3 As a more advanced measure, it should not be considered at all to process passwords in clear on the SP’s premises, given that the hash could have been performed at the IU client side.4 It can be argued that using biometric characteristics such as fingerprints or irises for sensitive operations such as payments might put at risk the legitimate users of the service. 5 Besides a full-fledged e-signature, a typical solution provides for the customer to input into his/her token/card reader some transaction details so that the generated OTP is linked to the latter.6 The formula is derived from the binomial distribution, summing the probability mass function from 1 to K to yield the probability to have at least one successful try.7 With respect to this kind of attack, an OTP can be assessed as less secure than an ordinary password with proper password policy and management. In fact, the information entropy H of a randomly generated six-digit OTP (calculated by the formula H = Llog2N with L = 6 and N = 10) evaluates to about 20 bits, while according to the US National Institute of Standards and Technology (NIST) Electronic Authentication Guideline, a human-generated eight-character password using mixed case numbers and symbols can be accredited of an entropy of about 24 bits.
Alessandro Campi is a technical officer at the Banking Supervision Department of Banca d’Italia (Italian Central Bank). Campi works in IT risk in the banking sector, taking part in technical working groups at both the local and European levels. Coming from the software industry, he formerly served as an IT internal auditor and contributed to develop IT security policies and IT risk analysis frameworks.
Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2012 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.