Entrust. Entrust IdentityGuard 8.1. Deployment Guide. Document issue: 2.0. Date of Issue: April 2007

(1)

Entrust

Entrust IdentityGuard 8.1

Deployment Guide

Document issue: 2.0

Date of Issue: April 2007

(2)

Entrust is a trademark or a registered trademark of Entrust, Inc. in certain countries. All Entrust product names and logos are trademarks or registered trademarks of Entrust, Inc. in certain countries. All other company and product names and logos are trademarks or registered trademarks of their respective owners in certain countries.

This information is subject to change as Entrust reserves the right to, without notice, make changes to its products as progress in engineering or manufacturing methods or circumstances may warrant.

Export and/or import of cryptographic products may be restricted by various regulations in various countries. Export and/or import permits may be required.

(3)

*About this guide

This guide discusses how to deploy Entrust IdentityGuard in an enterprise or consumer environment.

Note: The guide is not intended to be an exhaustive list of all the activities and

tasks required to deploy Entrust IdentityGuard. It acts as a guide for the team responsible for deployment.

Topics in this chapter:

• “Revision information” on page 13

• “Documentation conventions” on page 14

• “Related documentation” on page 15

• “Obtaining documentation” on page 16

• “Obtaining technical assistance” on page 17

This guide contains the following sections:

• “About Entrust IdentityGuard” on page 19 describes Entrust IdentityGuard and what it does.

• “Authentication choices” on page 27 describes and compares the authentication methods and how to deploy them.

• “Planning your deployment” on page 57 describes Entrust IdentityGuard deployment planning considerations.

• “Deployment considerations” on page 73 describes how to integrate Entrust IdentityGuard into your existing applications.

• “Deploying grid authentication” on page 87 describes, in detail, how to deploy grid authentication.

• “Deploying token authentication” on page 109 describes, how to deploy token authentication.

• “User life cycle management” on page 113 describes the life cycle for an Entrust IdentityGuard user.

(12)

• “Entrust IdentityGuard baseline architectures” on page 123 describes various architectures for deploying Entrust IdentityGuard.

• “Card usability study” on page 145 describes a study completed to examine card usability aspects.

(13)

Revision information

The following sections include updated information.

Table 1: Revisions in this document

Revision Section Description

Document issue 2.0 “Token

authentication” on page 31

“Using tokens for authentication” on page 110

Updates the information on token authentication.

(14)

Documentation conventions

Following are typographic conventions which appear in this guide:

Note and Attention text

Throughout this guide, there are paragraphs set off by ruled lines above and below the text. These paragraphs provide key information with two levels of importance, as shown below.

Note: Information to help you maximize the benefits of your Entrust product.

Attention: Issues that, if ignored, may seriously affect performance, security, or

the operation of your Entrust product.

Table 2: Typographic conventions

Convention Purpose Example

Bold text

(other than headings)

Indicates graphical user interface elements and wizards

Click Next.

Italicized text Used for book or document titles

Entrust TruePass 7.0 Deployment Guide

Blue text Used for hyperlinks to other sections in the document

Entrust TruePass supports the use of many types of digital ID.

Underlined blue

text

Used for Web links For more information, visit our Web site at

www.entrust.com. Courier type Indicates installation

paths, file names, Windows registry keys, commands, and text you must enter

Use the entrust-configuration.xml file to change certain options for Verification Server.

Angle brackets < >

Indicates variables (text you must replace with your organization’s correct values)

By default, the entrust.ini file is located in <install_path>/conf/security/entrust. ini. Square brackets [courier type] Indicates optional parameters

(15)

Obtaining documentation

Entrust product documentation, white papers, technical notes, and a comprehensive Knowledge Base are available through Entrust TrustedCare Online. If you are registered for our support programs, you can use our Web-based Entrust TrustedCare Online support services at:

https://www.entrust.com/trustedcare

Documentation feedback

You can rate and provide feedback about Entrust product documentation by completing the online feedback form. You can access this form by

• clicking the Feedback on guide link located in the footer of Entrust’s PDF documents (see bottom of this page).

• following this link: http://www.entrust.com/products/feedback/index.cfm

Feedback concerning documentation can also be directed to the Customer Support email address.

(17)

Obtaining technical assistance

Entrust recognizes the importance of providing quick and easy access to our support resources. The following subsections provide details about the technical support and professional services available to you.

Technical support

Entrust offers a variety of technical support programs to help you keep Entrust products up and running. To learn more about the full range of Entrust technical support services, visit our Web site at:

http://www.entrust.com/

If you are registered for our support programs, you can use our Web-based support services.

Entrust TrustedCare Online offers technical resources including Entrust product documentation, white papers and technical notes, and a comprehensive Knowledge Base at:

https://www.entrust.com/trustedcare

If you contact Entrust Customer Support, please provide as much of the following information as possible:

• your contact information

• product name, version, and operating system information • your deployment scenario

• description of the problem

• copy of log files containing error messages

• description of conditions under which the error occurred

• description of troubleshooting activities you have already performed

Telephone numbers

For support assistance by telephone call one of the numbers below: • 1-877-754-7878 in North America

• 1-613-270-3700 outside North America

Email address

The email address for Customer Support is:

(18)

Professional Services

The Entrust team assists e-businesses around the world to deploy and maintain secure transactions and communications with their partners, customers, suppliers and employees. We offer a full range of professional services to deploy our e-business solutions successfully for wired and wireless networks, including planning and design, installation, system integration, deployment support, and custom software

development.

Whether you choose to operate your Entrust solution in-house or subscribe to hosted services, Entrust Professional Services will design and implement the right solution for your e-business needs. For more information about Entrust Professional Services please visit our Web site at:

(19)

Chapter 1 About Entrust IdentityGuard

Entrust IdentityGuard is a multifactor authentication product that enhances the security and verifiability provided by a first-factor authentication system. It allows end users to prove their identity when accessing sensitive resources from their Microsoft Windows desktop, remotely through a VPN connection, or over the Web.

This chapter includes the following sections:

• “Why use Entrust IdentityGuard?” on page 20

• “Entrust IdentityGuard users” on page 22

(20)

Why use Entrust IdentityGuard?

As online fraud and compliance regulations become more prevalent, standard user name and password authentication no longer offers sufficient security to your organization’s sensitive resources.

Strong authentication is a tool that your organization likely uses in some form today. Whether it is for VPN remote access, Microsoft® Windows® security, or Web-based applications, you need to provide strong and flexible authentication to a wide range of users and transactions, based on the risk associated with those transactions. Entrust IdentityGuard provides multiple authentication factors (also referred to as “methods”) which your organization can add to its initial user name and password authentication methods to increase security. The various authentication methods Entrust IdentityGuard offers allows you to adjust the strength of the authentication to the sensitivity of the resource or transaction.

For example, as the following diagram demonstrates, a company could add Entrust IdentityGuard grid authentication to the user name and password authentication when a remote employee logs in using a VPN connection.

Topics in this section:

• “Challenges of single-factor authentication” on page 21

• “Benefits of multilayer authentication” on page 21

Employee repository Entrust IdentityGuard

Server

User name and password authentication resource

Company VPN device

Company firewall End user that

requires multifactor authentication

(21)

Challenges of single-factor authentication

Authentication is the process of determining whether someone or something is, in fact, who or what it presents itself as. In private and public computer networks, authentication is commonly done through the use of a user name and password. The user enters their password to authenticate to the application. This method is referred to as “single-factor authentication”.

However, the rapid increase in online identity theft shows that user names and passwords alone—which are easy to steal and easy to reuse—are not much defense against the ever-increasing sophistication of identity attacks. You need one or more second-factor authentication methods.

Benefits of multilayer authentication

“Multilayer authentication” is a solution that adds as many authentication methods as required based on the security context. For example, you can require an employee to log in using a user name and password, a grid challenge, and at the same time, have the authentication application check the computer they are using to ensure it is registered.

By adding multiple layers of authentication, an organization accomplished two things: • Identities become difficult to steal.

With multifactor authentication, it is difficult, if not impossible, for an attacker to steal login data in large numbers. While it is possible to physically steal some authentication data on an individual basis, attackers are usually interested in mass theft. They will get frustrated by the effort. Also, an organization can authenticate itself to its users, making it easier for users to detect redirection to a fraudulent site. The user can then take immediate countermeasures against the likely theft.

• Stolen identities become difficult to reuse.

Your organization can combine multiple authentication factors in ways that make the theft of a single factor useless to the attacker. Without the additional authentication factors, the attacker has either no access to a user’s confidential information or can only view trivial information. Also,

authentication can be performed at the transaction level making use of different authentication factors depending on the risk associated with the transaction.

(22)

Entrust IdentityGuard users

Entrust IdentityGuard users are divided into different categories, based on how they access your organization’s resources. See “Entrust IdentityGuard baseline

architectures” on page 123 for diagrams on how Entrust IdentityGuard interacts with these users.

The user categories are:

• Microsoft Windows desktop users

These are internal users who, after logging in to your domain using their Windows user name and password, are then challenged for a second factor of authentication (grid authentication). For more information on these users, refer to the Entrust IdentityGuard Desktop Client for Microsoft Windows

Administration Guide.

• Routing and Remote Access Service (RRAS) users

These are Microsoft Windows users internal to your organization who access your domain remotely through a dial-up, wireless, or VPN connection and use the Microsoft Routing and Remote Access Service. After logging in to your domain, they are then challenged for a second factor of authentication (grid authentication). For more information on these users, refer to the

Entrust IdentityGuard Desktop Client for Microsoft Windows Administration Guide.

• VPN users

These are internal or external users who log into your domain using a VPN connection. The first-factor of authentication (usually a user name and password) can be provided by an existing Remote Authentication Dial In User Service (Radius) server, or Entrust IdentityGuard can leverage Directory or Domain-based authentication information to complete the first-factor authentication itself. Entrust IdentityGuard then challenges these users for a second factor of authentication (either grid or token). For more information, refer to “VPN remote access integration” on page 75.

• Web users

These are internal or external users to your organization who access your intranet or Internet site by logging in through a Web browser. The first-factor of authentication is completed by a Web access product, and Entrust IdentityGuard can then provide different multi-factor authentication methods as required by the sensitivity of the operation the user wishes to perform. For more information, refer to “Web integration” on page 74.

(23)

Entrust IdentityGuard components

The following diagram shows how Entrust IdentityGuard fits into your existing authentication system. The Entrust IdentityGuard Server and optional components are further described in this section.

• “Entrust IdentityGuard Server” on page 23

• “Repository” on page 24

• “First-factor authentication application” on page 25

• “Entrust IdentityGuard Radius proxy” on page 25

• “Entrust IdentityGuard Desktop for Microsoft Windows” on page 25

• “Entrust IdentityGuard Remote Access Plug-in” on page 26

Entrust IdentityGuard Server

Entrust IdentityGuard Server is the main component of the Entrust IdentityGuard system. It includes the applications and interfaces required to authenticate and manage users and their authentication data:

• authentication and administration Web services with Java Platform and C# APIs

• administration interface and master command shell

Entrust IdentityGuard Server Repository End user First-factor authentication application

(24)

• sample Web application that demonstrates Entrust IdentityGuard’s capabilities

Repository

Entrust IdentityGuard uses your existing repository to store user data. When a grid or other authentication data is generated for a user, sensitive data is written in encrypted form to the repository. During user authentication, data is retrieved from the repository.

User data is stored in an existing LDAP-compliant Directory (including Active Directory) or a database. If you are using an LDAP-compliant Directory as your repository, consider the following:

• If your user population is split over multiple search bases in separate directories, you need to set up search bases in Entrust IdentityGuard. Entrust IdentityGuard has combined the support for user groups (see “Group requirements” on page 69) with support for multiple search bases. It can support multiple search bases for a single group and has the capability to use a single search base to cover multiple groups. Each search base has the capability of using a different Directory server and Directory user credentials. The default configuration uses a single search base.

• If you are using grid or token authentication, and will be pre-producing the grids or are loading the unassigned token information into the Entrust IdentityGuard system, this information is stored:

– as a flat file on the Entrust IdentityGuard Server (default) – in a separate database, if storing over a 100,000 cards or tokens For more information on the file-based repository options, refer to the

Entrust IdentityGuard Installation Guide. When the grid or token is assigned to a user, the information is then populated into their Directory entry. You can set up your repository in a failover scenario. For example:

• If you are using Active Directory or an LDAP-compliant Directory, you can add multiple URLs to the Entrust IdentityGuard property file. Entrust IdentityGuard will then attempt to connect to the directories in the order you have listed them.

• If you are using a database, you can set up automatic DNS updates, so that, should the primary database fail, the DNS entry of the database host changes to a secondary entry. This method requires database drivers that support automatic updates and disabling of Java network caching in Entrust IdentityGuard.

For more information on failover, refer to “High availability and disaster recovery” on page 80.

(25)

First-factor authentication application

Entrust IdentityGuard integrates with your existing authentication application using the Entrust IdentityGuard authentication and administration Web services, which are used for retrieving challenge requests, authenticating user responses, and managing users and authentication data.

This application can be a Radius server, a domain controller, a Web-based access control product, the Microsoft Windows Login feature, and so on. Depending on the type of application, you may need to customize it. For more information, see

“Deployment considerations” on page 73.

Entrust IdentityGuard Radius proxy

The Entrust IdentityGuard Radius proxy component installs with the Entrust

IdentityGuard Server to enable second-factor authentication (either grid or token) for VPN users. It intercepts messages between the VPN server and the first-factor authentication resource. That resource may be a Radius server, a Windows domain controller or an LDAP-compliant Directory. If the resource is a domain controller or Directory, you must use external authentication. For more information, see “External authentication” on page 56.

Once your VPN server uses the Radius proxy for first-factor authentication, you can configure Entrust IdentityGuard to add second-factor authentication methods to the first-factor authentication performed by the Radius proxy.

Entrust IdentityGuard Desktop for Microsoft

Windows

The purpose of the Entrust IdentityGuard Desktop for Microsoft Windows is to be a small-footprint client that communicates with the Entrust IdentityGuard Server. It provides strong second-factor authentication to the following:

• Windows Login - Microsoft Windows 2000 or Windows XP desktop (online or offline).

The Windows Login feature of the Entrust IdentityGuard Desktop for Microsoft Windows allows users to use second-factor grid authentication when they log in to their Microsoft Windows desktop computer.

• Remote Access - Network access through dial-up, wireless, or Virtual Private Network (VPN) remote access.

The Microsoft Routing and Remote Access Service (RRAS) feature enables users to remotely access a network through dial-up or VPN connectivity. When RRAS is installed on the Microsoft Windows desktop computer, a separate product called the Remote Access Plug-in for Microsoft Windows Server must be installed on a Microsoft Server machine.

(26)

Entrust IdentityGuard Desktop Manager is deployed using a Windows installer (.msi) file. You can customize the installer file by applying a transform (.mst file), which is a collection of changes applied to a base .msi file. A central administrator creates a custom installation file and configures the Entrust IdentityGuard options in accordance with your organization’s policies and practices. Refer to the Entrust

IdentityGuard Desktop for Microsoft Windows Administration Guide for more information.

Entrust IdentityGuard Remote Access Plug-in

The Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server communicates with the Entrust IdentityGuard Desktop for Microsoft Windows Remote Access feature.

For the Remote Access feature to connect to a Remote Access Server, the Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server must be installed on one of the following supported servers:

• Microsoft Routing and Remote Access Service (RRAS) • Microsoft Internet Authentication Service (IAS)

Usually, the RRAS and IAS are on the same computer. If your setup requires these to be on separate computers, it is recommended you install the Remote Access Plug-in on the computer hosting the IAS.

When the Remote Access Plug-in for Microsoft Windows Server is installed, an Entrust IdentityGuard Desktop for Microsoft Windows Remote Access client has the ability to connect to the Entrust IdentityGuard Server for user authentication. Refer to the Entrust IdentityGuard Desktop for Microsoft Windows Administration

(27)

Chapter 2 Authentication choices

Entrust IdentityGuard provides several authentication choices for your organization to authenticate your users, perform mutual authentication, and register computers. This chapter provides information that describes the implementation considerations for each method.

Note: While reading this chapter, consider the frequency of authentication

events to which you want to add multifactor authentication. Ensure you gather statistics from your authentication applications and resources, and develop a usage profile for each of the transactions. You can then find an appropriate balance between user convenience, resistance to attack, and the administrative overhead for managing multifactor authentication.

Topics in this chapter:

• “Overview of available authentication methods” on page 28

• “Authentication choices for users” on page 31

• “Authentication choices for deploying organizations” on page 51

• “Temporary PIN authentication” on page 55

(28)

Overview of available authentication

methods

This section describes and compares the authentication methods available through Entrust IdentityGuard, and the advantages and considerations of each.

Entrust IdentityGuard divides the authentication methods into two categories: • User authentication means the user verifies their authenticity to your

organization. Examples of user authentication are: – token authentication

– grid authentication

– passcode list authentication – knowledge-based authentication – out-of-band authentication – machine authentication

(29)

• Organization authentication means your organization proves itself as authentic. Examples of organization authentication involve different types of replay authentication.

Combining user and organization authentication methods allows you to set up

mutual authentication. Mutual authentication means both the user and your

organization verify themselves as legitimate. Mutual authentication works as follows:

• The user completes first-factor authentication successfully.

• Entrust IdentityGuard presents the user with a challenge based on the authentication method.

• The user enters the requested values.

• Entrust IdentityGuard validates the entered values and authenticates the user.

The Entrust IdentityGuard Server installs with a sample Web application that demonstrates how the various authentication methods work, and how you can set up your own applications to integrate with the Entrust IdentityGuard system. The

Serial replay authentication (grid card serial number )

Message replay authentication (user entered message) Image replay authentication (user selected image )

Grid location replay authentication (grid locations shown specific to

(30)

Entrust IdentityGuard Installation Guide includes a tutorial that describes what the sample Web application does.

To deploy the authentication methods, Entrust IdentityGuard includes policy attributes that allow you to determine the characteristics of the authentication method for groups of users. For more information, see “Entrust IdentityGuard policies” on page 59 and the Entrust IdentityGuard Administration Guide. The following table provides a brief comparison of the Entrust IdentityGuard authentication methods.

Table 3: Comparison of available authentication methods to each other Authentication

method

Physical

requirements for end users

Renewal options1

1. An administrator or application can force a renewal at any time.

Sample use

Token Token hardware when battery dies (expected 6 to 8 years)

Requiring strong second-factor authentication Grid Card Based on use or time Requiring strong

second-factor authentication Passcode list Printed List Based on use or time Requiring infrequent

one-time authentication Temporary PIN None Based on use or time Card, passcode list, or

token is unavailable Knowledge-based None N/A Registering users and/or

machines Out-of-band None2

2. Users need a telephone number, SMS information, or email account in order to receive the one-time password.

One-time use only One-time highly sensitive operation

Machine N/A Based on each login, time, or when users change computers

Users access organization from personally-owned computers

Replay (mutual) Card, if using grid location or serial number replay

N/A Verification of organization

(31)

Authentication choices for users

From a single deployed solution, your organization can choose one or more

second-factor methods of authenticating users. The choice depends on the risk of a given transaction or the sensitivity of your resources. The greater the risk of

misrepresentation and fraud, the greater the need for additional authentication. The following user authentication methods are available:

• “Token authentication” on page 31

• “Grid authentication” on page 32

• “Passcode lists” on page 37

• “Knowledge-based authentication” on page 38

• “Out-of-band authentication” on page 43

• “Machine authentication” on page 44

Considerations for each are described in the following sections.

Token authentication

Entrust IdentityGuard supports Entrust tokens and some third-party tokens. With tokens, your end users can authenticate themselves using a token dynamic password after completing first-factor authentication. Tokens represent a stronger method of user authentication than knowledge factors alone because they combine possession (the token) and knowledge (the dynamic password). Because the password changes frequently, it is impossible for a hacker to record it and use it later to log in to the system.

Entrust IdentityGuard supports tokens that use response-only mode: a single call validates the user-entered password. It does not support challenge/response mode.

Entrust tokens

Entrust offers robust, competitively priced token devices (and the accompanying token data file) designed to easily integrate with Entrust IdentityGuard applications. Entrust tokens do not require a token PIN (also known as a static PIN). Order Entrust tokens directly from Entrust. (For more information, see “Using tokens for

authentication” on page 110.)

Other tokens

Entrust IdentityGuard supports tokens from some third-party vendors. For details, refer to the Entrust TrustedCare Online Web site.

(32)

Grid authentication

With grid authentication, you provide each user with a printed Entrust IdentityGuard card that contains an assortment of characters in a row and column format.

Authentication works as follows:

• The user completes first-factor authentication successfully.

• Entrust IdentityGuard presents the user with a challenge based on the grid on their card, as illustrated in Figure 1.

• The user enters the values from their card corresponding to the requested cell locations in the challenge. In Figure 1, the challenge asks the user to enter the numbers in grid coordinates B1, E4, and G5, which are “7 8 4”. • Entrust IdentityGuard validates the entered values and authenticates the

user. By entering the correct response, users demonstrate that they possess the card, thus providing a second factor of authentication.

Table 4: Token authentication advantages and considerations Advantages • It is easy for end users to use.

• It is impossible for a hacker to re-use password, making it a very secure second-factor authentication method.

Considerations • You need to determine whether to use static token PINs, if available.

• You need to determine how to roll out tokens and train users. • Tokens are time synchronous, and therefore the Entrust

IdentityGuard Server clock must be accurate to UTC within a 30-second range.

Deployment types • Web access

• Microsoft Windows remote access • VPN remote access

(33)

Figure 1: Entrust IdentityGuard challenge sample

You can set up grid challenges in one of the following ways: • One-step authentication

In one-step authentication, you combine first and second-factor

authentication on a single page. For example, you include the prompt for a user name, a password and a grid challenge on one page. In this approach, the application does not know the identity of the user until after login and authentication; that is, the user is anonymous until both first and

second-factor authentication are complete. For an example, see Figure 2 on page 34.

John Smith

******

John Smith

(34)

Figure 2: One-step authentication example

• Two-step authentication

In two-step authentication, the user logs in as usual and is then shown a second dialog containing the Entrust IdentityGuard grid challenge. Because the user has already passed first-factor authentication, the user’s identity is known. This lets you add other Entrust IdentityGuard features, such as serial number replay or grid location replay (see “Authentication choices for deploying organizations” on page 51). For an example, see Figure 3 on page 35.

(35)

(36)

The following table lists some of the advantages and considerations of grid authentication.

Table 5: Grid authentication advantages and considerations

Advantages • It is easy for end users to use (see “Entrust IdentityGuard card usability study” on page 146).

• It has a low cost to set up and maintain.

• If an attacker manages to observe several completed logins including the grid authentication challenge and response, they gain only a fraction of the total grid data.

Considerations • Consider grid size. For example, a 5 x 10 grid contains 16,000 three-cell challenge sets. Since Entrust IdentityGuard selects the challenge sets randomly or on a least used basis, knowing a few possible challenge-and-response combinations is useless to an attacker because the next challenge is certain to request different cells.

• Consider grid lifetime. Given that it is unlikely that the attacker would receive the same challenge set captured from an earlier attack, the attacker would be forced to guess at the coordinates. As the attacker obtains more and more of a user’s grid contents, less guessing is required. Regular replacement of cards with newly generated grids can help mitigate this risk.

• Determine whether you need one-step or two-step authentication options (two-step is recommended).

Deployment types • Web access

• Microsoft Windows remote access • VPN remote access

• Microsoft Windows desktop

Deployment risks and mitigation

• The most likely form of attack is verifier impersonation or “man-in-the middle” combined with online guessing. Through mechanisms such as phishing or pharming, an attacker can capture one or more grid authentications made by the user and thus capture some information on their card. Subsequently, an attacker could use this information to attempt to authenticate to the legitimate application.

• A very important aspect of these attacks is that they are generally short lived. Typical phishing and pharming incidents last only a few days. According to the Anti-Phishing Working Group (APWG)—as of March 2005—the average life of a phishing site is 5.8 days.

(37)

Passcode lists

Passcode list authentication is a type of grid authentication that uses a list of passcodes or transaction numbers (TANs) rather than a card. Each number can be used just once. With this approach, you provide users with a list of randomly generated passcodes for second-factor authentication.

Some organizations view passcode lists as easier for their users to use than cards, though our usability study proved card use is quick to learn. (See “Card usability study” on page 145.)

Typically, you distribute these to users on a printed sheet of paper similar to Figure 4.

Figure 4: Sample passcode list

Then, when a passcode is required, you prompt for the passcode next to a number in the list as in Figure 5.

(38)

The user types the passcode printed on the paper next to the requested number. To reduce susceptibility to phishing or malware attacks, each passcode is used just once. This renders the entered passcode useless should it be captured by an attacker. To help end users remember the one-time use restriction, recommend that they strike used passcodes from the list. Alternatively, create your passcode list as a scratch card, which only reveals the passcode once a covering is scratched off.

Knowledge-based authentication

One of the simplest mechanisms for gaining additional confidence in the identity of users is to challenge them to provide information that an attacker likely cannot

Table 6: Passcode list authentication advantages and considerations

Advantages • One-time use of a password makes it impossible for attackers to reuse authentication data.

• You can create multiple one-time passwords at once, lowering overhead.

Considerations • Much like the production of a grid, you need to produce and distribute the passcode lists to your users. Unlike grids, however, you will typically wish to send users more than one list at a time. Research your past authentication histories to determine how fast the average user will exhaust a list and send an appropriate number of lists to ensure that users can always authenticate. • Additional consideration should be given to the way a passcode

list is produced, such as whether it will be a simple list of uncovered passcodes or a covered list much like a lottery scratch card. Cost will be the primary difference between these two options.

• The number of characters in each passcode should be between five and nine to ensure security and to maintain usability. • Choose between numeric or alphanumeric passcodes.

Deployment type • Web access

Deployment risks and mitigation

• Some phishing attacks target this form of authentication. There are simple ways to increase the security of a passcode list. For example, prompt for passcodes in a random order instead of from first to last. Consider adding another form of authentication, such as machine authentication in conjunction with a passcode list. Alternatively, consider deploying grid authentication instead of a passcode list.

(39)

provide. The organization can present questions to the user based on information (referred to as authentication secrets) that was supplied by the user at registration or based on previous transactions or relationships.

The users in turn recognize the secret questions they set up during registration; so, they know they are at a legitimate site.

For example:

• During enrolment the user may select and provide answers to easily-remembered questions, such as Your most memorable cartoon

character, Which historical figure do you most admire, and so on. • Questions can be drawn from previous user interactions with the

organization. Examples include: What was the balance on your last

statement and How often do you make mortgage payments. These have the advantage of being harder for attackers to harvest through other information sources.

Entrust IdentityGuard allows organizations to select a number of such authentication secrets or facts for each user and prompt for all answers or just a subset to increase user authentication strength.

Figure 6: Sample question-and-answer prompt

By maintaining a large set of authentication secrets, organizations can select a subset that makes it more difficult for an attacker to gather impersonating information based on previous authentications.

• “Sources of questions” on page 40

• “Creating good questions” on page 41

• “Ensuring answer consistency” on page 42

(40)

Note: Many of the concepts discussed in the following sections were first

presented by Mike Just, in “Designing and Evaluating Challenge-Question Systems,” IEEE Security & Privacy, vol. 02, no. 5, pp. 32-39, September-October, 2004.

Sources of questions

There are a variety of methods for developing the questions for knowledge-based authentication. Here are some ideas:

• Generated codes

One of the most common approaches is to generate PINs and TANs for users and deliver them to a known address (email or postal). These numbers represent a simple form of question. This approach applies to existing users and is extremely useful for encouraging them to register for new services. • Transaction data

One approach for existing users is to use transaction data, such as the date and balance of a recent statement. In this approach, the application extracts the data from an existing database to form the questions. This ability to import data into Entrust IdentityGuard permits an organization to leverage information that is already known about users as a part of knowledge authentication.

Organizations wanting to import data need to use Entrust IdentityGuard’s Administration API through an application written for each customer environment. This custom application executes the necessary Entrust IdentityGuard calls to import and manage the data on a per user basis. Entrust Professional Services can help organizations with this type of customizing task. For contact information, see “Obtaining technical assistance” on page 17.

• Prepopulated lists

It may be necessary to have users register their own question-and-answer response sets. To do this, present them with a stock list of questions from which they make selections and provide answers. This approach gives the organization control over the questions to ensure they meet criteria for privacy, security, and usability. (See also “Creating good questions”.) • User-generated

While you can allow users to enter their own question-and-answer

challenges, this approach is not recommended. In general, users do not write well formed questions or provide well crafted clues that meet criteria for privacy, security, and usability. Also, users tend to forget the answers to their own questions more frequently than stock questions. However, in a design

(41)

that makes use of multiple question-and-answer sets, it may make sense to allow one question and answer that is composed entirely by the user.

Creating good questions

Your choice of questions has a direct impact on the success of knowledge-based authentication. Measure the questions you select against the following criteria:

• Privacy

Organizations are subject to legislation and regulations relating to the collection, storage, control, and handling of personal information. It is prudent to avoid the use of personal information when building a knowledge-based authentication system. Construct the information collected for question-and-answer sets so that it is used exclusively for authentication purposes.

• Security

Construct questions so that the answers are both difficult to obtain and difficult to guess. For privacy reasons, do not rely on personal information such as names, family histories and birth dates. Also, identity thieves regularly find or steal personal information. This renders the reliability of this information almost nil. A question such as What is your mother’s maiden

name? is less secure than asking a more difficult personal question, such as

What is your father’s middle name?

Avoid questions that have a limited number of realistic answers. For example,

What is my eye color? would not require many attempts to guess a correct answer.

• Usability

Knowledge-based authentication must be simple and easy for users to use. Consider these ease-of-use criteria:

– Applicability

The questions should have a wide applicability to the organization’s users. For example, the question What is the name of my first pet? only applies to pet owners.

– Memorability

An answer must be easily recalled for the question to be useful. Questions that reflect user’s habits, regular activities, or practices generally meet this criteria.

– Repeatability

Answers need to remain constant for the question to be of value. Questions that prompt for a “favorite” may have different responses over time, while those that ask for a “first” should not change. Repeatability also deals with

(42)

consistency—the ability to enter an identical response each time. This is discussed next under “Ensuring answer consistency”.

Ensuring answer consistency

Knowledge-based authentication relies on an exact match between the stored answer and the response at the time of authentication. (The mechanism actually involves secure hash values, although the effect is the same—the original and subsequent answers must be identical.)

Employ the following techniques to improve the chances of receiving an exact match: • Normalize the data.

The application should process response data to ensure consistent presentation. This can involve removing “white space,” converting all alphabetic characters to lowercase, ignoring punctuation and special characters, and so on.

• Standardize responses.

Questions that require answers formatted in a standard way, especially dates, should include drop-down lists or other mechanisms that enforce a

standardized response.

• Avoid syntactic representations.

What do you expect the answer to look like; for example, having to process “St.” as “Street”? This requires thoughtful creation of the question.

• Validate the answer set.

You should include rules-based post-processing of the answers given during enrolment to ensure answer quality. You don’t want the same response to each question, nor sequential keyboard sequences, nor repeated characters, and so on. Many of the rules that apply to good password quality also apply to good answer quality. Your application can reject answers that don’t fit your rules and prompt for a better answer.

Selecting a set of questions

A common practice is to create several question-and-answer sets during the enrolment process, then use a randomly selected subset for subsequent

knowledge-based authentication. In addition, your application can use dynamic transaction data not stored by Entrust IdentityGuard to supplement the knowledge authentication. Answers to questions such as When was your last mortgage

payment? or What was your last transaction value? could be presented and validated outside of Entrust IdentityGuard. Such questions incrementally add to the overall security of the deployment.

(43)

For usability reasons, users will not tolerate answering a large number of questions for enrolment and especially not at the time of authentication. Although you may require the user to select and answer only a few questions during authentication, it is recommended that you have a large selection of questions available. This increases the odds that each user will find an appropriate set of questions and it increases the system’s resistance to attack by making it more difficult for an attacker to anticipate a given user’s questions.

To make it easier on users, you can use questions and answers for additional authentication rather than your main second-factor authentication. For example, use machine authentication for the user’s normal login location and reserve the questions if the user logs in from a different machine.

Out-of-band authentication

Out-of-band authentication uses an independent means to communicate with the end user to protect against attacks that have compromised the primary channel. Entrust IdentityGuard supports this capability by generating a one-time password you can send with a transaction summary to the user. You can send this information directly using email or SMS, or by voice to a registered phone number. The user gets the confirmation number by one of these means, enters it, and the transaction is approved.

To decide how to send the one-time password, consider the following:

• What information you already store about the end user and consider reliable. For example, a cell phone service provider would likely use SMS with its digital cell service users. This way, the service provider can manage any service level agreement (SLA).

• If you do not consider previously collected information to be reliable enough for out-of-band authentication, you can register users. For example, SLAs may also play a role in the use of SMS, as it is not always 100% reliable. The registration process allows users to enter, validate, and correct their delivery information (email address, voice phone number, and cell phone number) and out-of-band authentication preferences. This also allow users to

(44)

personalize the way that their confirmation number is delivered to them—a definite user benefit.

Machine authentication

Machine authentication provides validation of the user’s computer to secure the user against a variety of threats. It is an especially attractive method where end users typically access their accounts from the same computer. It allows for seamless authentication without any noticeable impact to the user experience.

This section describes ways of gathering machine fingerprint information (also called the machine secret) and the implications of storing and validating the information gathered. It also discusses requirements for machine authentication that may influence how machine authentication is used.

To establish the computer identity:

• Entrust IdentityGuard first generates a fingerprint of the user’s computer. This fingerprint is based on the following configured set of machine parameters that can be transparently read from the user’s computer: – Machine nonce: This is an arbitrary number generated by Entrust

IdentityGuard for authentication purposes when Entrust IdentityGuard registers the machine.

– Optional sequence nonce: Entrust IdentityGuard generates and changes the sequence nonce each time authentication occurs. A sequence nonce

Table 7: Out-of-band authentication advantages and considerations

Advantages • It is effective at guarding against attacks such as

man-in-the-middle, where a legitimate session may be used to piggy-back fraudulent transactions.

• It can leverage channels that already exist and are easy for users to access. These include telephone calls, SMS to a cell phone, or email to a computer or mobile device. All these allow the user to confirm a particular transaction using a channel already registered with the organization.

Considerations • When sending the password, ensure that you also provide a context as to what the user is getting the password for. • Consider the sensitivity of the transaction details, as users may

not always delete the message immediately, and it may be sent unprotected.

• The expiry time for the password should balance the amount of time it would take a user to receive your message and enter the password with your need for security.

(45)

assures that the machine secret is only valid until the next login attempt. This increases security by reducing the validity period of the machine information, and by making it more difficult for an attacker to use the cookies without being detected.

– Optional application data: This is a list of name and value pairs specified by a client application and set when Entrust IdentityGuard first creates the machine secret. A client application can provide Entrust IdentityGuard with application data specific to the user’s computer. This can include operating system and browser versions gathered through simple methods that do not require client-side software.

• Entrust IdentityGuard generates a computer identity reference and stores it on the computer for future authentication. This computer registration process is similarly performed for all computers a user wishes to register. In Figure 7, the simple action of selecting the option Remember me on this

machine sets machine authentication into action. Figure 7: Login page with machine authentication

• During subsequent logins, Entrust IdentityGuard: – retrieves the computer identity transparently – authenticates it

– recalculates the computer fingerprint

– compares it to the one stored for that computer

Entrust IdentityGuard’s machine authentication thus provides protection for users even if they have had their authentication data stolen by attackers. Because an attacker would not likely try to enter the stolen credentials from the user’s computer, the machine authentication fails and the attacker can’t obtain access.

(46)

Sources of machine information

There are several ways to create a fingerprint of a particular computer. The choice depends on the method chosen to gather fingerprint data.

Basic Web browser without client-side software: This requires a Web browser only.

From the user’s perspective, it is the least invasive method of gathering the information for a machine fingerprint.

Your program needs to set a cookie within the browser for subsequent authentication comparisons of the user’s machine fingerprint. Take this into consideration when deploying machine authentication.

There are two ways of gathering data from a Web browser without requiring client-side software. You can use the browser Get request or Javascript.

Through a Web browser Get request, the application can identify a browser using the HTTP headers present in the browser’s request to the server. Unfortunately, all data returned is quite predictable, even to an attacker who has never seen a particular browser’s request. Figure 8 shows a sample Get request.

Figure 8: Sample browser Get request

GET /cgi-bin/inputdump.exe HTTP/1.1 Accept: */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: anyserver.anybank.com Connection: Keep-Alive

Cookie: intranetredirectURL=; GA_SHOW_TABS=; LASTSITE=intranet

Due to the predictability of standard Get requests from a browser, we recommend not to use these fields on their own. Some fields (such as user-agent) may be useful as part of a broader machine fingerprint. Use other methods described below to create a unique machine fingerprint.

Instead of Get requests, your Web application can use standard Javascript calls to gather information. This involves a minor modification to the application’s login page to collect the wider range of data needed for the machine fingerprint. All the following pieces of information are available through standard Javascript calls without requiring any client-side software.

(47)

Note: The properties in Table 8 were collected using JavaScript on an Internet Explorer browser running on Windows. Similar properties will be available on other browsers, but their names and values will vary.

Table 8: General properties

Property Value

navigator.appCodeName Mozilla

navigator.appName Microsoft Internet Explorer navigator.appMinorVersion ;SP2;

navigator.cpuClass x86 navigator.platform Win32 navigator.systemLanguage en-us

navigator.userLanguage en-us

navigator.appVersion 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR

2.0.50727)

navigator.userAgent Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) navigator.onLine true navigator.cookieEnabled true screen.availHeight 1170 screen.availWidth 1600 screen.bufferDepth 0 screen.colorDepth 32 screen.deviceXDPI 96 screen.deviceYDPI 96 screen.fontSmoothingEnabled true screen.height 1200 screen.logicalXDPI 96 screen.logicalYDPI 96

(48)

Note: The properties in Table 9 and Table 10 show just a portion of the MIME and plug-in information available. They were collected using JavaScript on a Firefox browser running on Windows. Similar properties will be available on other browsers, but their names and values will vary.

Table 9: MIME properties (partial list).

Given the wide range of information available, some of which may be too common to be useful, we recommend that organizations consider the use of a combination of elements gathered through Javascript such as:

• browser version.

screen.updateInterval 0

screen.width 1600

navigator.mimeTypes[0].description Mozilla Default Plug-in navigator.mimeTypes[0].suffixes * navigator.mimeTypes[0].type * navigator.mimeTypes[1].description Java navigator.mimeTypes[1].enabledPlugin. filename NPOJI610.dll

Table 10: Plug-in information (partial list)

navigator.plugins[0].description Default Plug-in navigator.plugins[0].filename npnul32.dll navigator.plugins[0].length 1

navigator.plugins[0].name Mozilla Default Plug-in

navigator.plugins[1].description Java Plug-in 1.5.0 for Netscape Navigator (DLL Helper)

Table 8: General properties

(49)

• browser plug-ins present. • browser language being used.

• browser platform (user’s operating system). • screen size of user’s computer (height and width). • screen color depth.

Basic Web browser with client-side software: Organizations can deploy signed Java

applets or ActiveX controls that can go beyond basic browser security. This involves the user seeing and accepting security notifications on a regular basis. While more secure, it is less than ideal for large-scale consumer deployments. However, there may be instances where this is the best practice since it allows organizations to gather more detailed physical machine data for use in a machine fingerprint. Elements that could be gathered in this scenario include:

• media access control (MAC) address of the user’s Ethernet card.

• exact operating system (OS) information including the service pack and patch level.

• system information including native byte order and number of available processors.

• hardware information (manufacturer, model, version, and so on) of various hardware devices (network card, video card, hard drive, CD reader/writer, processor type).

• CPU processor ID (if enabled).

• user information (account name and home Directory).

The above elements can be combined with other available elements to create the machine fingerprint.

Web application (server-side): The information available through Javascript and

client-side software can be augmented by data available from the Web application.

Figure 9 shows information gathered by a simple server-side CGI.

Figure 9: Sample Web application data

HTTP_USER_AGENT=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 HTTP_ACCEPT=text/xml,application/xml,application/xhtml+xml,text/ht ml;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5 HTTP_ACCEPT_ENCODING=gzip,deflate HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_KEEP_ALIVE=300 HTTP_CONNECTION=keep-alive HTTP_COOKIE=LASTSITE=anybank; intranetredirectURL=https%3A//anyserver.anybank.com/download/cnbc. htm; GA_SHOW_TABS=0%2C1%2C2%2C4

(50)

REMOTE_ADDR=10.4.132.9 REMOTE_PORT=1294

This information is similar to that found in a Get request (see Figure 8 on page 46). This list includes a port and IP address. Port information may change each time and is not a useful property for a machine fingerprint. A user’s IP address can be used to look up geolocation information, but shouldn't be used directly.

Entrust IdentityGuard can store additional application data specified by your organization, including data that may be gathered with standard APIs through external data sources. (For example, geolocation services can estimate the geographic location of the user based on their PC’s IP address.)

Table 11: Machine authentication advantages and considerations

Advantages • It provides users with a seamless login experience.

Considerations • Determine whether users ever access your site through a public computer (such as from a library)

• Determine how to obtain the machine information (depending the browser type, a client-side application, and so on). See the

Entrust IdentityGuard Programming Guidefor further information.

• Determine how many properties in the machine secret must be successfully matched for successful authentication. Failure may depend on the property in question. If one of the properties captured is the browser version and in subsequent

authentications that version changes (perhaps the user upgraded the browser), it may still make sense to allow that user access. It is recommended that organizations examine their user base carefully before configuring this option in order to maximize security and overall usability.

• Determine whether to use a sequence nonce to update the machine secret each time the user logs in.

• Determine whether to add application data to the machine secret.