David Chou
Microsoft Corporation

August 2008

Summary: Focusingon methods that are used to implement strong user authentication foronline-consumer identities, this article aims to distill a comprehensive viewof strong user authentication by examining its concepts, implementationapproaches, and challenges/additional concerns at the architectural level. Itdiscusses effective solution approaches, overall architecture design, andemerging developments. (10 printed pages)

Contents

Introduction
Strong UserAuthentication
ArchitecturalPerspectives
State-of-the-Art
Final Thoughts
Conclusion
Resources

Introduction

Identity theft remains one of the more prevalent issues onthe Internet today. Studies indicate that digital identity fraud is still onthe rise, with an increase in sophistication (that is, "phishing,""man-in-the-middle," DNS poisoning, malware, social engineering, andso forth) and an expansion of attack vectors (that is, unregulated financialsystems, lottery and sweepstakes contests, healthcare data, syntheticidentities, and so on). With the upward trend of moving data and services intothe Web and cloud-based platforms, the management and control of access toconfidential and sensitive data is becoming more than verifying simple usercredentials at the onset of user sessions for one application, and with higherinterconnectivity and interdependencies among multiple applications, services,and organizations.

One of the more exploited methods today is the gaining ofaccount access by stealing reusable credentials for Web sites that have not yetimplemented "strong" user authentication. This is so, because mostcommon forms of credentials today are knowledge-based (that is, user ID andpassword) and are requested only once during sign-on, which provides a higherlevel of convenience to users, but also requires less effort for attackers toexploit. Many attacks are manifested as "phishing" messages thatmasquerade as ones that are sent by legitimate organizations and contain URLsthat point to fraudulent Web sites that have the same appearances as genuineones. Often, they act as "man-in-the-middle" and eventually doforward visitors to the actual Web sites; but, in the process, they havecaptured valid credentials that can be used to gain access to actual accounts.

The ease with which online identities can be stolen and usedeffectively has prompted many organizations and governing bodies to raisealarms. In the U.S., the October 2005 Federal Financial InstitutionsExamination Council (FFIEC) "Authentication in an Internet Banking Environment"guide identified that simple-password authentication is insufficient forensuring authorized access to important financial services. Many otherregulatory provisions also have identified similar needs, such as the HomelandSecurity Presidential Directive (HSPD)-12, Electronic Signatures in Global andNational Commerce (E-SIGN) Act, Federal Information Processing StandardsPublication (FIPS PUB) 201-1, HIPAA, SOX, GLBA, PATRIOT, and so on.

Subsequently, various methods have been developed to improve the"strength" of an authentication system in withstanding identity-theftattacks. While the spectrum of methods spans a wide range of concern areas—suchas enterprises, consumers, hardware, mobility, and so on—this article focuseson methods that are used to implement strong user authentication foronline-consumer identities. It discusses effective solution approaches, overallarchitecture design, and emerging developments.

Strong User Authentication

So, how do we improve Web-based user-authentication systemswithout compromising usability and ubiquity, when the Internet is accessedmostly through a browser that has limited access to the client environment andhardware devices? The most common solution approaches that are used todayinvolve, in more generalized terms, various forms of enhanced shared-secretand/or multifactor authentication.

Enhanced shared-secret authentication refers to extensionsof conventional knowledge-based (single-factor) authentication—for example,additional passwords, site keys, preregistered graphical icons to supportmutual authentication, challenge-response, randomized code selections that arebased on input patterns, CAPTCHA, and so on.

Multifactor authentication refers to a compoundimplementation of two or more classes of human-authentication factors:

·        Somethingknown to only the user—Knowledge-based (for example, password, pass phrase,shared secrets, account details and transaction history, PIN, CAPTCHA, and soon).

·        Somethingheld by only the user—Possession-based (for example, security token, smartcard, shared soft tokens, mobile device, and so on).

·        Somethinginherent to only the user—Biological or behavior biometric traits (for example,facial recognition, fingerprint, voice recognition, keystroke dynamics,signature, and so on).

For example, many enterprise extranet/VPN solutions todayrequire both simple credentials (something known, such as ID and password) andhardware tokens (something held, such as secure ID with time-based one-time passwordgenerators, smart cards that use embedded PKI solutions, and so on) in order togain access. The combination of the two "known" and "held"factors makes up the multifactor authentication method, and significantlyimproves the authentication strength, as it curtails the threat of stolendigital identities.

In practice, however, there is a wealth of implementations,methods, and permutations of them—all with varying trade-offs in terms of cost,complexity, usability, and security. Next, let's discuss viable solutionapproaches.

Solution Approaches

Now, not all of the available strong-authentication optionsthat are available today lend themselves well to the Web. Conventionalmultifactor authentication methods (that involve the deployment of custom hardwaretokens, such as RSA SecurID, smart cards, and so on) are effective for closedcommunities—such as employees and partners—but they are too costly,inconvenient, and logistically difficult—for example, distribution,administration, management, support, and so on—for the open consumercommunities on the Web. In this case, authentication solutions have to workprimarily within the confines of the browser's security sandbox. Here, wediscuss a few solution approaches that are relatively cost-effective to implementfor online consumers, based on today's standards:

Figure 1a. Knowledge-based authentication

·        Knowledge-basedauthentication (KBA) typically is implemented as extensions to existingsimple-password authentication. Knowledge-based credentials include choseninformation, personal and historical information, on-hand information,deductive and derived responses, patterns, images, and so on. However, itgenerally boils down to additional set(s) of challenge-response that allowsusers to prove that the claimed identities belong to them. Some well-knownexamples include Bank of America's "SiteKey," HSBC's virtual keyboard,and so on. KBA is used also as an identity-verification method for self-servicepassword-reset processes; but, when implemented effectively, they can be usedas methods to complement primary authentication. This approach moderatelyimproves authentication strength, as it is still single-factor (in-band withinthe browser) and prone to phishing attacks, but it might be sufficient for someWeb sites.

Figure 1b. Server-generated OTP

·        Server-generatedone-time passwords (OTPs) commonly are implemented as randomized passwordstrings that are generated in real time after verifying simple-passwordcredentials. Some more advanced implementations combine KBA elements tofacilitate derived OTPs (such as server-generated grid cards for shared patternrecognition, digitally signed OTPs that are based on server-generated data, andso on). The generated OTPs then are delivered to users via a different channel(out-of-band) from the session in the browser, such as e-mail, SMS (ShortMessage Service) text messaging to mobile devices, direct phone calls that usecomputer-generated speech, and so on. Users then can use the OTP to sign-in tothe application, by entering it into a designated field on the page.

Many organizations in the public sector have started todeploy this type of solution to implement strong user authentication. Thisapproach significantly improves authentication strength as it employstwo-factor authentication and out-of-band delivery of OTPs. However, it stillis not completely secure, as it is prone to the "man-in-the-middle"real-time phishing attacks that try to capture and use the OTP in real time.Plus OTP delivery latencies potentially could affect overall user experience.

Figure 1c. Client-generated OTP

·        Client-generatedone-time passwords are similar to conventional OTP hardware tokens (such as RSASecurID, VeriSign VIP OTP, and so on). However, with the level ofnear-ubiquitous proliferation of mobile devices today, cellular phones havebecome a viable alternative as the soft-token (or "something held")authentication factor. In this case, individualized cryptographic softwarecomponents can be installed on mobile devices to generate time-based or event-basedOTPs. Users then can use the OTP to sign-in to the application afterauthenticating simple Web-based credentials (examples include RSA SecurIDsoftware, Java ME applications, and so on). This approach has the benefits ofOTPs, not having to deal with out-of-band delivery latencies and inconsistentservice coverage.

Figure 1d. Out-of-band authentication

·        Out-of-band(OOB) authentication leverages the second factor for authentication, instead ofdelivery of individualized information. Current implementations include speechrecognition that is facilitated via out-bound or in-bound voice calls (to/fromland or cellular lines) or KBA via SMS request/reply. This type of solutionoffers higher authentication strength, as both the browser and a second factorare used to verify credentials, which works to impede common phishing attacks.

In general, these high-level approaches rank in increasingrelative authentication strength. However, higher authentication strength doesnot necessarily represent the best-of-breed solution, as security oftenrequires trade-offs in user convenience. Studies indicate that different userpopulations respond differently to strong-authentication methods. The choice ofan approach (or combinations of approaches) should consider user segments, aswell as the types of activities and interactions that they perform with theapplication. For example, online consumers who view account balances(considered a relatively low-risk type of activity) should requirecomparatively less effort to access than consumers who conduct accounttransfers or physicians who view patient's medical records.

Finally, the implementation of strong user authentication oftenis a balancing act between security and usability. Many implementations havenot achieved their intended effectiveness by either delivering significantlydeteriorated user experiences or compromising security postures by simplysatisfying requirements on paper. Furthermore, there is no one-size-fits-allsolution approach. For example, not all Web sites require multifactorauthentication, while enhanced knowledge-based authentication might be"secure enough"; and some carefully designed single-factor methodsactually might be "stronger" than some multifactor methods. Awell-balanced design tends to be more cost-effective than force-fitting variousbest-of-breed approaches into one solution.

Architectural Perspectives

We've just discussed how strong user authentication can beimplemented as a component of a Web application architecture. Are there otherareas of concerns and challenges that we should pay attention to, and how doesthis component affect or relate to the rest of the architecture?

From an architectural perspective, strong user authenticationinvolves more than just ensuring an effective identity and credentialsverification at the point of user sign-on. A fully integrated and highlycoordinated architecture is required to deliver an effective strong userauthentication. Let's discuss here the more prevalent aspects and challenges ofa strong user-authentication architecture.

Identity Proofing

Identity proofing is the process of verifying useridentities (for example, if a user is indeed who the individual claims to be)before provisioning user credentials. A strong user-authenticationimplementation is ineffective, and the identity infrastructure becomesunreliable, if verifiable identity assurance cannot be ensured.

In-person identity proofing that is based on valid IDs andcredentials remains one of the more reliable methods today, and is commonlyused by various financial, government, and healthcare organizations. On theother hand, in self-service scenarios in which identity proofing is handledcompletely online, organizations typically use knowledge-based systems toverify user identities. However, in this case, the pieces of information thatare requested from an individual for identification purposes should be resistantto social-engineering attacks.

Furthermore, the same level of identity proofing is requiredalso when reissuing credentials (for example, resetting passwords, recoveringforgotten IDs, requesting elevated access, and so on) and terminatingcredentials. Compromising the level of strength in identity proofing in anystage of an identity's life cycle will affect adversely the overall effectiveauthentication strength.

The point at which user provision occurs is also where additionalauthentication factors should be registered and associated with a new user'sprofile; these factors are used then to support strong user authentication—forexample, answering sets of challenge-response to support KBA,registering/verifying a mobile phone number to support out-of-band OTPdelivery, capturing voice recordings to support speech recognition, and soforth.

Integration Architecture

A comprehensive, robust, and reliable user-authenticationsystem is becoming more than a database-driven component of one stand-aloneapplication. A strong-authentication system must be tightly integrated andsynchronized with the security infrastructure in an organization, such asidentity management (IdM), Web access management (WAM), enterprise singlesign-on (ESSO), certificate and key management (PKI), vulnerability management,audit management, policy management, user directories/repositories, and so on.In some cases, these systems provide capabilities that can be leveraged toimplement a strong-authentication system, while some downstream systems dependon the authentication system to pass relevant contextual information andauthenticating decisions (for example, role-mapping) that are needed for userauthorization and access control.

Increasingly, an organization's security infrastructure willinclude capabilities that live in the cloud (or are hosted by other serviceproviders). Although these services do not reside in an organization's owninfrastructure, the same integration concerns and security-access policies andrequirements still must be applied consistently, in order to maintain auniformly reliable security architecture.

Layered Approach

The initial logon page does not have to be the only point atwhich users are authenticated. A layered approach can be implemented, so thatdifferent strength levels of authentication are implemented in different areas,according to the varying levels of data confidentiality and/or value. When itis implemented with a balanced design between data requirements andauthentication strengths and points, this approach can improve overallusability while ensuring security, as it allows convenient access to lessconfidential areas of a Web site, and more credentials are required only toaccess the more confidential areas. Furthermore, additional authentication/verificationcan be required on individual transactions that are deemed more risky. Thesepotentially can leverage the stronger authentication methods, such asmultifactor and out-of-band authentication approaches.

Alternatively, in systems that have implemented role-based accesscontrol (RBAC) for user authorization, different methods of authentication canbe presented to users who are mapped to different roles; or, in a more dynamicimplementation, if a user logs on by using partial credentials (whenhigher-strength credentials are made optional), that user is mapped to a rolethat has lower access privileges for that Web session.

Risk-Based Analytics

Risk-based analytics are similar to what credit cardcompanies use to assess risk levels for each requested transaction and makeauthorization decisions in real time. Assessments are based on real-timeevaluation of various data points that are collected about the user and therequested transaction; depending on the scoring and data-confidentiality requirements,a transaction can be authorized or unauthorized, or additional credentials canbe requested from the user to facilitate stronger authentication and reliableauditing.

The data points that are collected often are contextualinformation (or location-based, behavior-based, and so on) and used assupplemental credentials to support strong authentication. For example,client-device identification (CDI) can be used to simplify valid repeatedauthentication requirements from the same client device, if a verified set ofcredentials has signed in to a Web site from the same device previously. Thisis often facilitated by saving specific "remember me" cookies, andsometimes by using a combination of data points that are collected from theHTTP request and client-side JavaScript code. Subsequently, based on therisk-based assessment that the same user had signed in successfully to the sameapplication previously, a lower-strength authentication is presented to theuser to improve convenience.

Historical and social data points also are included often inthe risk assessment, and often are used from the perspective oftransaction-anomaly detection (TAD), as these data points help establish a"normal" usage profile about a user and can be compared against therequested transaction to identify contextual anomalies. For example, atransaction that is identified with unusual characteristics (for example,originating from a different physical location, different client device,unusual time of day/week, fund transfers to new and unverified account, and soon) contributes to a higher risk profile, which prompts the authenticationsystem to require stronger authentication from the user in order to authorizethe transaction.

This is also referred to as fraud detection, and it works welltogether with a layered approach to implement a dynamically adaptiveauthentication system.

Compensating Controls

An authentication system also can take into account othercomponents that are not integrated directly into this architecture, which canpotentially influence (positively or negatively) users' security posturesand/or risk profiles, and contribute to risk-based analysis. For example,Extended Validation SSL (EV-SSL), digital watermarking, site keys, and so oncontribute to mutual authentication and help improve end-user behavior, whichin a way improves the risk profile. Host intrusion detection, anti-spyware,anti-phishing network services, and so on all contribute to a user's overallrisk profile.

Figure 2: Strong user authentication architecture components

Finally, the view of authentication architecture that ispresented here falls on the more comprehensive and complex side of the variousdesign approaches. It certainly is not required for all organizations toimplement all of the identified capabilities, but can serve as a reference toeach implementation project to support evaluation of required capabilities, andassess how they should be implemented—although some complex enterpriseenvironments might require this level of meticulous planning and design inorder to deliver an effective identity-assurance infrastructure andproficiently safeguard important data.

However, regardless of how simple or complex each implementationmight be, it is necessary that security policies and authentication systems beapplied homogeneously to all user-contact surfaces. An inconsistentimplementation across the entire operational architecture could expose certainloopholes for attackers to exploit; and, sometimes, these can includenontechnical areas, such as administrative processes, instructions forcall-center customer service reps, and so on.

State-of-the-Art

Several emerging megatrends also influence developments in theonline user-authentication space. Let's discuss both their impacts and how theyare related to strong user-authentication concerns.

Cloud Computing

From a user-authentication perspective, moving data into thecloud and integrating cloud-based services should be implemented with the samelevel of overall effective authentication strength as the enterpriseperspective of authentication architecture. However, organizations havesignificantly less control over the authentication strengths of theinterdependent cloud-based services of their counterparts/partners. Forexample, whether via identity federation or delegation, the overall securityposture of the resulting interconnected architecture can be compromised if theintegrated services themselves have comparatively lower-strength authenticationsystems in place.

The same is true for SaaS (software-as-a-service) providers,as extra attention must be focused on ensuring appropriate levels of authenticationsstrengths for different user communities in a multitenancy model, withoutcompromising overall and individual security and usability.

Thus, the focus on authentication systems becomes one of theprimary evaluation factors for organizations that are looking to adoptcloud-based services. Organizations must ensure that service providers providethe flexibility to deliver varying levels of strong authentication to meetrequired security policies, or extend existing security implementations by leveragingidentity federation (via SAML or WS-Federation) or authentication delegation tosupport single sign-on (SSO) or reduced sign-on (RSO). However, in these cases,organizations must incur the costs to deploy secure and accessibleidentity-federation and/or authentication-delegation services.

From a capabilities perspective, many of the authenticationarchitecture components are being deployed as cloud-based services—for example,identity-proofing services that are deployed by credit bureaus, consumer-identityframeworks and providers, vulnerability-management networks, PKI andcertificate-management services, secondary-factor channel providers (voicetelephony, SMS messaging, speech recognition, patterns recognition, and soforth), fraud detection, strong-authentication service providers, and so on.These services provide much-needed capabilities to compose astrong-authentication system; however, the same integration-security concernsremain such that any one weak link in the connected-systems architecture willcompromise the overall security posture.

Identity Metasystems

The consumer-identity frameworks that are available now ascloud-based platforms and their growing adoption means that organizationseventually will need to integrate these identity metasystems to improve userconvenience—for example, OpenID identity providers, Google Account, WindowsLive ID, Yahoo! ID, and so on—although, in order to integrate these onlinecommunities, the authentication strengths that are implemented for theseservices must be evaluated against the security policies and requirements forthe organizations that are looking to leverage them.

Similarly, online identity providers increasingly will need toadd flexibility to configure varying levels of authentication strengths fordifferent user segments, in addition to integrating various authentication formfactors and standards (Higgins, PKCS, OpenID, Windows Cardspace, and so on) ifthey intend to provision services to data-sensitive organizations.

Smart-Card Proliferation

With the availability of more sophisticated smart-cardsolutions and ecosystem support, more physical credentials are adoptingsmart-card (standard plastic cards embedded with microprocessors and/orintegrated circuits) deployments. For example, many countries and states (forexample, Austria, Belgium, Estonia, Hong Kong, and Spain) already have rolledout government-sponsored electronic ID programs to national citizens.Subsequently, smart cards are becoming another form of authentication factor,where smart-card readers are available and are integrated into authenticationsystems.

Furthermore, many vendors are consolidating multipleauthenticators into the ISO 7816 smart-card form factor—for example, integratedLCDs to display OTPs, and biometric (fingerprint) readers. We might findsmart-card deployments materialize in more cases, such as from financialinstitutions that already are issuing physical credentials (that is, creditcards, debit cards, and so on). Cryptographic smart cards that use biometric readersprovide very high identity assurance, as they tightly bind the private keys tothe users' biometrics (multifactor authentication).

Mobile Identity

From a physical-hardware perspective, SIM (SubscriberIdentity Module) cards have improved significantly in terms of storage capacityand capability to perform cryptographic processing. Computing power and memorycapacity also have improved exponentially in mobile devices. Subsequently, theSIM card and mobile phone have become the smart card and smart-card reader thatconstitute the most ubiquitous "something held" (or in-possession)authentication factor.

This makes it possible to store symmetric keys on SIM cardsand, along with simple cryptographic software modules, to turn the mobiledevice into a seeded OTP generator. The generated OTPs can be used ascredentials for out-of-band, multifactor authentication.

Furthermore, with wireless data plans, mobile devices cancommunicate directly with authentication systems by using wireless PKI. In thiscase, SIM cards provide secure storage of users' private PKI keys. The privatekeys then can be used to facilitate strong authentication—implemented withcorresponding certificates to facilitate digital signatures—and, in some cases,to facilitate client-authenticated SSL. Some of the projected applications ofthis approach include mobile banking, contactless/proximity mobile payments,identity and credential verification, and so on. At some point, mobile devicesmight become the most ubiquitous form of mobile digital identities forconsumers.

Final Thoughts

So, it appears that a user-authentication system forconsumer communities on the Web is growing beyond the traditionaldatabase-driven and/or directory-driven component of a Web application, fororganizations that have higher data-confidentiality requirements.Implementation approaches for strong authentication span a full spectrum thatranges from highly integrated and interconnected/dependent to simple extensionsof existing stand-alone architectures.

Building a strong user-authentication architecture requiresfocus beyond just improving the credential-verification component. The overallarchitecture might include additional aspects, such as a layered system that isdriven by risk-based analytics, which enables an adaptive authenticationsystem. Also, the design of an authentication approach should be weighedagainst various requirements, such as data (that is, availability,confidentiality, integrity, accountability, and so on), identity assurance,usability, compliance and auditing, portability/scalability, manageability, anduser-community dynamics. More importantly, however, just the same as othersecurity initiatives, strong user authentication also requires a carefullyplanned, well-balanced, and concerted approach across the entire ITarchitecture to ensure a consistently secure environment.

With the growing adoption of cloud-based services,consumer-identity metasystems, and mobile devices, while attack methods gain maturityand sophistication, the future outlook for strong user authentication is setfor many innovative developments.

Conclusion

The escalating trend of moving data and services into thecloud also necessitates methodical planning to ensure secure access toauthorized users over the Internet. While existing simple-password–basedauthentication might continue to work for many consumer-oriented Web sites, itsinherent vulnerabilities have been identified as security risks forinstitutions that have higher data-privacy requirements. To mitigate the riskof online identity fraud, organizations look to strong user authentication asthe solution for improving their Web-based authentication systems.

However, implementing strong user authentication often is not a straightforwardtask, as projects have myriad options from which to choose, a multitude oftrade-offs to consider, and a cluster of intricacies to manage. This articlehas intended to distill a comprehensive view of strong user authentication byexamining its concepts, implementation approaches, and challenges andadditional concerns at the architectural level.

Resources

Authentication in an Internet Banking Environment, FederalFinancial Institutions Examination Council. http://www.ffiec.gov/pdf/authentication_guidance.pdf

Electronic Authentication Guideline v1.0.1, NationalInstitute of Technology Special Publication 800-63 (NIST SP 800-63).

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

Policy for a Common Identification Standard for FederalEmployees and Contractors, Homeland Security Presidential Directive-12(HSPD-12).

http://www.whitehouse.gov/news/releases/2004/08/20040827-8.html

Personal Identity Verification of Federal Employees andContractors, Federal Information Processing Standards Publication 201-1 (FIBSPUB 201-1).

http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

Electronic Signatures in Global and National Commerce Act,United States Congress E-SIGN Act.

http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_bills&docid=f:s761enr.txt.pdf

A Guide to Understanding Identification and Authenticationin Trusted Systems, National Computer Security Center (NCSC-TG-017).

http://www.csirt.org/color_%20books/NCSC-TG-017.pdf

Computer Security Guidelines for Implementing the PrivacyAct of 1974, FIPS PUB 41.

http://www.itl.nist.gov/fipspubs/fips41.pdf

Security Requirements for Cryptographic Modules, FIPS PUB 140-2.

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

About the author

David Chou is an architect in the Developer & PlatformEvangelism organization at Microsoft, where he collaborates with localorganizations in architecture, design, and proof-of-concept projects. Drawingon experiences from his previous jobs at Accenture and Sun Microsystems, Davidenjoys helping customers create value from using objective and pragmaticapproaches to define IT strategies and solution architectures. David maintainsa blog at http://blogs.msdn.com/dachou,and can be reached at david.chou@microsoft.com. 

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the ArchitectureJournal Web site.