How Strong is Strong User Authentication? 

 
Download Article Article in Digital Form

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.

Raising Security of Authentication Procedures

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:

  1. Knowledge—Something the user knows, e.g., a password, a personal identification number (PIN)
  2. Ownership—Something the user has, e.g., token, smart card, mobile phone/SIM
  3. Inherence—Something the user is, e.g., fingerprint

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:

  • Two or more security factors can be combined to yield a strong multilayered solution, but only if they are all sound. Indeed, combining a weak factor with a stronger factor does not add much to the security provided.
  • The selected factors, as used in the envisaged solution, must be mutually independent so that the compromising of one does not impact the protection level offered by the other(s).

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.

Independence and Quality Characteristics

As a consequence of the aforementioned considerations, an organization should seek a solution that entails:

  • The independence of generation and transmission means of the different factors’ authentication codes. If the use of an independent channel is not viable, it is advisable to adopt ownership/ inherence factors that generate short lifetime, non-reusable authentication codes, so that the risk of misuse of an intercepted or stolen code is mitigated.
  • Authentication factors that are designed and managed to be uniquely bound to the legitimate user.

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.

Figure 1

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).

Implementations in Use

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:

  1. The use of a password plus a grid card—Since a grid card can be easily replicated, it cannot be considered a viable ownership factor. In addition, legitimate users in general have no way to detect if fake copies of their cards have been made, thus they will continue using the system at the same time as the fraudster.
  2. The use of a password plus a secret stored on the access device (e.g., software digital certificates, smartphone applications, embedding authentication codes)—As long as secrets stored in the AD can be surreptitiously stolen via the Internet (e.g., through the use of malware) and used many times by the fraudster, their use together with the user password cannot be considered a sound implementation of strong authentication.
  3. A hardware token-generating OTP to be used together with the IU customer identifier (e.g., banking account number)—Since a customer identifier is not designed and managed to be known only by the legitimate user, this is a single-factor solution and, as such, it does not provide strong authentication.
  4. A PIN-protected card used together with a card reader to obtain a OTP to access the SP site—In this case, a knowledge factor and an ownership factor are used, but the first PIN is used only to enable the card reader and only the OTP is transmitted to the verifying entity (the SP); therefore, a possible vulnerability of the OTP would affect the security of the whole solution, likely setting aside the protection offered by the PIN. As a result, since the security of the knowledge factor is dependent on that of the ownership, this case should not be regarded as a strong authentication solution.
  5. The use of a password plus an OTP generated and transmitted to the SP by an application stored on the IU’s mobile—Since the OTP is generated and transmitted via a second channel, this arrangement bears the features needed to provide strong authentication. However, viruses have been detected that are able to transmit from a smartphone to a PC (or vice versa) when they are connected (e.g., to synchronize their data). Therefore, specific measures to strengthen the independence of the two channels should be considered, if it is deemed opportune on the basis of the relevant risk analysis.
  6. The combination of a password with an OTP generated by a (disconnected) hardware token—Given that these two authentication factors fulfill the requirements listed previously for knowledge and ownership factors (including, in particular, a very limited lifetime for the OTP), this widespread solution can provide an effective strong authentication. However, since the two authentication codes are put in the same device and interface, they are still vulnerable to real-time man-in-the- browser (MITB) attacks, usually via sophisticated malware. Hence, for operations requiring strict protection (e.g., high amount payments), this strong authentication can be complemented with even more advanced measures, such as the e-signature of the transaction.5

Is the OYP Alone Safe?

Figure 2To 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.

Conclusion

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.

Acknowledgements

The author wishes to thank Pietro Franchini and Ravenio Parrini for their review of this article and their feedback.

Disclaimer

The views expressed in this article are those of the author and are not necessarily those of Banca d’Italia.

Endnotes

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.