Assignment

JB12345

CH03-CompSec4e.pptx

Home >Information Systems homework help >Assignment

Computer Security:

Principles and Practice

Fourth Edition

By: William Stallings and Lawrie Brown

Lecture slides prepared for “Computer Security: Principles and Practice”, 4/e, by William Stallings and Lawrie Brown, Chapter 3 “User Authentication”.

Chapter 3

User Authentication

In most computer security contexts, user authentication is the fundamental building

block and the primary line of defense. User authentication is the basis for most

types of access control and for user accountability. User authentication encompasses two

functions. First, the user identifies herself to the system by presenting a credential,

such as user ID. Second, the system verifies the user by the exchange of authentication

information.

In essence, identification is the means by which a user provides a claimed identity

to the system; user authentication is the means of establishing the validity of the

claim. Note user authentication is distinct from message authentication. As defined in

Chapter 2, message authentication is a procedure that allows communicating parties

to verify that the contents of a received message have not been altered, and that the

source is authentic. This chapter is concerned solely with user authentication.

This chapter first provides an overview of different means of user authentication,

then examines each in some detail.

NIST SP 800-63-3 (Digital Authentication Guideline, October 2016) defines digital user authentication as:

“The process of establishing confidence in user identities that are presented electronically to an information system.”

NIST SP 800-63-3 (Digital Authentication Guideline , October 2016) defines digital

user authentication as the process of establishing confidence in user identities

that are presented electronically to an information system. Systems can use the

authenticated identity to determine if the authenticated individual is authorized

to perform particular functions, such as database transactions or access to system

resources. In many cases, the authentication and transaction, or other authorized

function, take place across an open network such as the Internet. Equally authentication

and subsequent authorization can take place locally, such as across a local

area network.

(Table can be found on page 65 in the textbook)

Table 3.1, from NIST SP 800-171 (Protecting Controlled Unclassified

Information in Nonfederal Information Systems and Organizations , December 2016),

provides a useful list of security requirements for identification and authentication

services.

NIST SP 800-63-3 defines a general model for user authentication that involves

a number of entities and procedures. We discuss this model with reference to

Figure 3.1.

The initial requirement for performing user authentication is that the user must

be registered with the system. The following is a typical sequence for registration. An

applicant applies to a registration authority (RA) to become a subscriber of a credential

service provider (CSP) . In this model, the RA is a trusted entity that establishes

and vouches for the identity of an applicant to a CSP. The CSP then engages in an

exchange with the subscriber. Depending on the details of the overall authentication

system, the CSP issues some sort of electronic credential to the subscriber. The

credential is a data structure that authoritatively binds an identity and additional

attributes to a token possessed by a subscriber, and can be verified when presented

to the verifier in an authentication transaction. The token could be an encryption

key or an encrypted password that identifies the subscriber. The token may be issued

by the CSP, generated directly by the subscriber, or provided by a third party. The

token and credential may be used in subsequent authentication events.

Once a user is registered as a subscriber, the actual authentication process can

take place between the subscriber and one or more systems that perform authentication

and, subsequently, authorization. The party to be authenticated is called a

claimant and the party verifying that identity is called a verifier . When a claimant

successfully demonstrates possession and control of a token to a verifier through an

authentication protocol, the verifier can verify that the claimant is the subscriber

named in the corresponding credential. The verifier passes on an assertion about the

identity of the subscriber to the relying party (RP) . That assertion includes identity

information about a subscriber, such as the subscriber name, an identifier assigned

at registration, or other subscriber attributes that were verified in the registration

process. The RP can use the authenticated information provided by the verifier to

make access control or authorization decisions.

An implemented system for authentication will differ from or be more complex

than this simplified model, but the model illustrates the key roles and functions

needed for a secure authentication system.

There are four general means of authenticating a user's identity, which can be used alone or in combination:

• Something the individual knows: Examples includes a password, a personal identification number (PIN), or answers to a prearranged set of questions.

• Something the individual possesses: Examples include electronic keycards, smart cards, and physical keys. This type of authenticator is referred to as a token.

• Something the individual is (static biometrics): Examples include recognition by fingerprint, retina, and face.

• Something the individual does (dynamic biometrics): Examples include recognition by voice pattern, handwriting characteristics, and typing rhythm.

All of these methods, properly implemented and used, can provide secure user authentication. However, each method has problems. An adversary may be able to guess or steal a password. Similarly, an adversary may be able to forge or steal a token. A user may forget a password or lose a token. Further, there is a significant administrative overhead for managing password and token information on systems and securing such information on systems. With respect to biometric authenticators, there are a variety of problems, including dealing with false positives and false negatives, user acceptance, cost, and convenience.

The four means of authenticating user identity are based on:

Something the individual knows

Password, PIN, answers to prearranged questions

Something the individual possesses (token)

Smartcard, electronic keycard, physical key

Something the individual is (static biometrics)

Fingerprint, retina, face

Something the individual does (dynamic biometrics)

Voice pattern, handwriting, typing rhythm

Multifactor authentication refers to the use

of more than one of the authentication means in the preceding list (see Figure 3.2).

The strength of authentication systems is largely determined by the number of factors

incorporated by the system. Implementations that use two factors are considered to

be stronger than those that use only one factor; systems that incorporate three factors

are stronger than systems that only incorporate two of the factors, and so on.

Risk Assessment for User Authentication

There are three separate concepts:

Security risk assessment in general is dealt with in Chapter 14. Here, we introduce a specific example as it relates to user authentication. There are three separate concepts we wish to relate to one another: assurance level, potential impact, and areas of risk.

Assurance Level

Potential impact

Areas of risk

Assurance Level

An assurance level describes an organization’s degree of

certainty that a user has presented a credential that refers to his or her identity.

More specifically, assurance is defined as (1) the degree of confidence in the vetting

process used to establish the identity of the individual to whom the credential was

issued and (2) the degree of confidence that the individual who uses the credential is

the individual to whom the credential was issued. SP 800-63-3 recognizes four levels

of assurance:

• Level 1: Little or no confidence in the asserted identity’s validity. An example

of where this level is appropriate is a consumer registering to participate in

a discussion at a company web site discussion board. Typical authentication

technique at this level would be a user-supplied ID and password at the time

of the transaction.

• Level 2: Some confidence in the asserted identity’s validity. Level 2 credentials

are appropriate for a wide range of business with the public where organizations

require an initial identity assertion (the details of which are verified

independently prior to any action). At this level, some sort of secure authentication

protocol needs to be used, together with one of the means of authentication

summarized previously and discussed in subsequent sections.

• Level 3: High confidence in the asserted identity’s validity. This level is appropriate

to enable clients or employees to access restricted services of high value

but not the highest value. An example for which this level is appropriate:

A patent attorney electronically submits confidential patent information to

the U.S. Patent and Trademark Office. Improper disclosure would give competitors

a competitive advantage. Techniques that would need to be used at

this level require more than one factor of authentication; that is, at least two

independent authentication techniques must be used.

• Level 4: Very high confidence in the asserted identity’s validity. This level is

appropriate to enable clients or employees to access restricted services of very

high value or for which improper access is very harmful. For example, a law

enforcement official accesses a law enforcement database containing criminal

records. Unauthorized access could raise privacy issues and/or compromise

investigations. Typically, level 4 authentication requires the use of multiple

factors as well as in-person registration.

Describes an organization’s degree of certainty that a user has presented a credential that refers to his or her identity

More specifically is defined as:

The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued

The degree of confidence that the individual who uses the credential is the individual to whom the credential was issued

Four levels of assurance

Level 1

Little or no confidence in the asserted identity's validity

Level 2

Some confidence in the asserted identity’s validity

Level 3

High confidence in the asserted identity's validity

Level 4

Very high confidence in the asserted identity’s validity

Potential Impact

FIPS 199 defines three levels of potential impact on organizations or individuals should there be a breach of security:

Low

An authentication error could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals

Moderate

An authentication error could be expected to have a serious adverse effect

High

An authentication error could be expected to have a severe or catastrophic adverse effect

A concept closely related to that of assurance level is potential

impact. FIPS 199 (Standards for Security Categorization of Federal Information and

Information Systems, 2004) defines three levels of potential impact on organizations

or individuals should there be a breach of security (in our context, a failure in user

authentication):

• Low: An authentication error could be expected to have a limited adverse

effect on organizational operations, organizational assets, or individuals. More

specifically, we can say that the error might: (1) cause a degradation in mission

capability to an extent and duration that the organization is able to perform its

primary functions, but the effectiveness of the functions is noticeably reduced;

(2) result in minor damage to organizational assets; (3) result in minor financial

loss to the organization or individuals; or (4) result in minor harm to individuals.

• Moderate: An authentication error could be expected to have a serious

adverse effect. More specifically, the error might: (1) cause a significant degradation

in mission capability to an extent and duration that the organization is

able to perform its primary functions, but the effectiveness of the functions is

significantly reduced; (2) result in significant damage to organizational assets;

(3) result in significant financial loss; or (4) result in significant harm to individuals

that does not involve loss of life or serious life threatening injuries.

• High: An authentication error could be expected to have a severe or catastrophic

adverse effect. The error might: (1) cause a severe degradation in or

loss of mission capability to an extent and duration that the organization is not

able to perform one or more of its primary functions; (2) result in major damage

to organizational assets; (3) result in major financial loss to the organization

or individuals; or (4) result in severe or catastrophic harm to individuals

involving loss of life or serious life threatening injuries.

Maximum Potential Impacts for Each Assurance Level

Table 3.2

The mapping between the potential impact and the appropriate

level of assurance that is satisfactory to deal with the potential impact depends on the

context. Table 3.2 shows a possible mapping for various risks that an organization

may be exposed to. This table suggests a technique for doing risk assessment. For

a given information system or service asset of an organization, the organization

needs to determine the level of impact if an authentication failure occurs, using the

categories of impact, or risk areas, that are of concern.

For example, consider the potential for financial loss if there is an authentication

error that results in unauthorized access to a database. Depending on the

nature of the database, the impact could be:

• Low: At worst, an insignificant or inconsequential unrecoverable financial

loss to any party, or at worst, an insignificant or inconsequential organization

liability.

• Moderate: At worst, a serious unrecoverable financial loss to any party, or a

serious organization liability.

• High: severe or catastrophic unrecoverable financial loss to any party; or severe

or catastrophic organization liability.

The table indicates that if the potential impact is low, an assurance level of 1

is adequate. If the potential impact is moderate, an assurance level of 2 or 3 should

be achieved. And if the potential impact is high, an assurance level of 4 should be

implemented. Similar analysis can be performed for the other categories shown in

the table. The analyst can then pick an assurance level such that it meets or exceeds

the requirements for assurance in each of the categories listed in the table. So, for

example, for a given system, if any of the impact categories has a potential impact of

high, or if the personal safety category has a potential impact of moderate or high,

then level 4 assurance should be implemented.

Password-Based Authentication

Widely used line of defense against intruders

User provides name/login and password

System compares password with the one stored for that specified login

The user ID:

Determines that the user is authorized to access the system

Determines the user’s privileges

Is used in discretionary access control

A widely used line of defense against intruders is the password system. Virtually all

multiuser systems, network-based servers, Web-based e-commerce sites, and other

similar services require that a user provide not only a name or identifier (ID) but

also a password. The system compares the password to a previously stored password

for that user ID, maintained in a system password file. The password serves

to authenticate the ID of the individual logging on to the system. In turn, the ID

provides security in the following ways:

• The ID determines whether the user is authorized to gain access to a system.

In some systems, only those who already have an ID filed on the system are

allowed to gain access.

• The ID determines the privileges accorded to the user. A few users may have

supervisory or “superuser” status that enables them to read files and perform

functions that are especially protected by the operating system. Some systems

have guest or anonymous accounts, and users of these accounts have more

limited privileges than others.

The ID is used in what is referred to as discretionary access control. For example,

by listing the IDs of the other users, a user may grant permission to them

to read files owned by that user.

Password Vulnerabilities

In this subsection, we outline the main forms of attack against password-based

authentication and briefly outline a countermeasure strategy. The remainder of

Section 3.2 goes into more detail on the key countermeasures.

We can identify the following attack strategies:

• Offline dictionary attack: Typically, strong access controls are used to protect

the system’s password file. However, experience shows that determined

hackers can frequently bypass such controls and gain access to the file. The

attacker obtains the system password file and compares the password hashes

against hashes of commonly used passwords. If a match is found, the attacker

can gain access by that ID/password combination. Countermeasures include

controls to prevent unauthorized access to the password file, intrusion detection

measures to identify a compromise, and rapid reissuance of passwords

should the password file be compromised.

• Specific account attack: The attacker targets a specific account and submits

password guesses until the correct password is discovered. The standard countermeasure

is an account lockout mechanism, which locks out access to the

account after a number of failed login attempts. Typical practice is no more

than five access attempts.

• Popular password attack: A variation of the preceding attack is to use a popular

password and try it against a wide range of user IDs. A user’s tendency

is to choose a password that is easily remembered; this unfortunately makes

the password easy to guess. Countermeasures include policies to inhibit the

selection by users of common passwords and scanning the IP addresses of

authentication requests and client cookies for submission patterns.

• Password guessing against single user: The attacker attempts to gain knowledge

about the account holder and system password policies and uses that

knowledge to guess the password. Countermeasures include training in and

enforcement of password policies that make passwords difficult to guess.

Such policies address the secrecy, minimum length of the password, character

set, prohibition against using well-known user identifiers, and length of time

before the password must be changed.

• Workstation hijacking: The attacker waits until a logged-in workstation is

unattended. The standard countermeasure is automatically logging the workstation

out after a period of inactivity. Intrusion detection schemes can be

used to detect changes in user behavior.

• Exploiting user mistakes: If the system assigns a password, then the user is

more likely to write it down because it is difficult to remember. This situation

creates the potential for an adversary to read the written password. A user

may intentionally share a password, to enable a colleague to share files, for

example. Also, attackers are frequently successful in obtaining passwords by

using social engineering tactics that trick the user or an account manager into

revealing a password. Many computer systems are shipped with preconfigured

passwords for system administrators. Unless these preconfigured passwords

are changed, they are easily guessed. Countermeasures include user training,

intrusion detection, and simpler passwords combined with another authentication

mechanism.

• Exploiting multiple password use. Attacks can also become much more

effective or damaging if different network devices share the same or a similar

password for a given user. Countermeasures include a policy that forbids the

same or similar password on particular network devices.

• Electronic monitoring: If a password is communicated across a network to

log on to a remote system, it is vulnerable to eavesdropping. Simple encryption

will not fix this problem, because the encrypted password is, in effect, the

password and can be observed and reused by an adversary.

Offline dictionary attack

Specific account attack

Popular password attack

Password guessing against single user

Workstation hijacking

Exploiting user mistakes

Exploiting multiple password use

Electronic monitoring

A widely used password security technique is the use of hashed passwords and

a salt value. This scheme is found on virtually all UNIX variants as well as on

a number of other operating systems. The following procedure is employed

(Figure 3.3a). To load a new password into the system, the user selects or is

assigned a password. This password is combined with a fixed-length salt

value [MORR79]. In older implementations, this value is related to the time

at which the password is assigned to the user. Newer implementations use a

pseudorandom or random number. The password and salt serve as inputs to a

hashing algorithm to produce a fixed-length hash code. The hash algorithm is

designed to be slow to execute in order to thwart attacks. The hashed password

is then stored, together with a plaintext copy of the salt, in the password file for

the corresponding user ID. The hashed password method has been shown to be

secure against a variety of cryptanalytic attacks [WAGN00].

When a user attempts to log on to a UNIX system, the user provides an ID

and a password (Figure 3.3b). The operating system uses the ID to index into the

password file and retrieve the plaintext salt and the encrypted password. The salt

and user-supplied password are used as input to the encryption routine. If the result

matches the stored value, the password is accepted.

The salt serves three purposes:

• It prevents duplicate passwords from being visible in the password file. Even if

two users choose the same password, those passwords will be assigned different

salt values. Hence, the hashed passwords of the two users will differ.

• It greatly increases the difficulty of offline dictionary attacks. For a salt of

length b bits, the number of possible passwords is increased by a factor of 2b,

increasing the difficulty of guessing a password in a dictionary attack.

• It becomes nearly impossible to find out whether a person with passwords on

two or more systems has used the same password on all of them.

To see the second point, consider the way that an offline dictionary attack

would work. The attacker obtains a copy of the password file. Suppose first that

the salt is not used. The attacker’s goal is to guess a single password. To that end,

the attacker submits a large number of likely passwords to the hashing function.

If any of the guesses matches one of the hashes in the file, then the attacker

has found a password that is in the file. But faced with the UNIX scheme, the

attacker must take each guess and submit it to the hash function once for each

salt value in the dictionary file, multiplying the number of guesses that must be

checked.

There are two threats to the UNIX password scheme. First, a user can gain

access on a machine using a guest account or by some other means and then run

a password guessing program, called a password cracker, on that machine. The

attacker should be able to check many thousands of possible passwords with little

resource consumption. In addition, if an opponent is able to obtain a copy of the

password file, then a cracker program can be run on another machine at leisure. This

enables the opponent to run through millions of possible passwords in a reasonable

period.

UNIX Implementation

Since the original development of UNIX, most implementations

have relied on the following password scheme. Each user selects a password

of up to eight printable characters in length. This is converted into a 56-bit value

(using 7-bit ASCII) that serves as the key input to an encryption routine. The hash

routine, known as crypt(3), is based on DES. A 12-bit salt value is used. The modified

DES algorithm is executed with a data input consisting of a 64-bit block of zeros. The

output of the algorithm then serves as input for a second encryption. This process is

repeated for a total of 25 encryptions. The resulting 64-bit output is then translated

into an 11-character sequence. The modification of the DES algorithm converts it

into a one-way hash function. The crypt(3) routine is designed to discourage guessing

attacks. Software implementations of DES are slow compared to hardware versions,

and the use of 25 iterations multiplies the time required by 25.

This particular implementation is now considered woefully inadequate. For

example, [PERR03] reports the results of a dictionary attack using a supercomputer.

The attack was able to process over 50 million password guesses in about 80 minutes.

Further, the results showed that for about $10,000 anyone should be able to do the

same in a few months using one uniprocessor machine. Despite its known weaknesses,

this UNIX scheme is still often required for compatibility with existing account management

software or in multivendor environments.

Original scheme

Up to eight printable characters in length

12-bit salt used to modify DES encryption into a one-way hash function

Zero value repeatedly encrypted 25 times

Output translated to 11 character sequence

Now regarded as inadequate

Still often required for compatibility with existing account management software or multivendor environments

Improved Implementations

There are other, much stronger, hash/salt schemes available for UNIX. The

recommended hash function for many UNIX systems, including Linux, Solaris,

and FreeBSD (a widely used open source UNIX), is based on the MD5 secure

hash algorithm (which is similar to, but not as secure as SHA-1). The MD5 crypt

routine uses a salt of up to 48 bits and effectively has no limitations on password

length. It produces a 128-bit hash value. It is also far slower than crypt(3). To

achieve the slowdown, MD5 crypt uses an inner loop with 1000 iterations.

Probably the most secure version of the UNIX hash/salt scheme was developed

for OpenBSD, another widely used open source UNIX. This scheme, reported in

[PROV99], uses a hash function based on the Blowfish symmetric block cipher. The

hash function, called Bcrypt, is quite slow to execute. Bcrypt allows passwords of

up to 55 characters in length and requires a random salt value of 128 bits, to produce

a 192-bit hash value. Bcrypt also includes a cost variable; an increase in the cost

variable causes a corresponding increase in the time required to perform a Bcyrpt

hash. The cost assigned to a new password is configurable, so that administrators can

assign a higher cost to privileged users.

Much stronger hash/salt schemes available for Unix

Recommended hash function is based on MD5

Salt of up to 48-bits

Password length is unlimited

Produces 128-bit hash

Uses an inner loop with 1000 iterations to achieve slowdown

OpenBSD uses Blowfish block cipher based hash algorithm called Bcrypt

Most secure version of Unix hash/salt scheme

Uses 128-bit salt to create 192-bit hash value

Password Cracking

The traditional approach to password guessing,

or password cracking as it is called, is to develop a large dictionary of possible

passwords and to try each of these against the password file. This means that

each password must be hashed using each salt value in the password file and then

compared to stored hash values. If no match is found, then the cracking program

tries variations on all the words in its dictionary of likely passwords. Such variations

include backward spelling of words, additional numbers or special characters, or

sequence of characters,

An alternative is to trade off space for time by precomputing potential hash

values. In this approach the attacker generates a large dictionary of possible passwords.

For each password, the attacker generates the hash values associated with

each possible salt value. The result is a mammoth table of hash values known as a

rainbow table. For example, [OECH03] showed that using 1.4 GB of data, he could

crack 99.9% of all alphanumeric Windows password hashes in 13.8 seconds. This

approach can be countered by using a sufficiently large salt value and a sufficiently

large hash length. Both the FreeBSD and OpenBSD approaches should be secure

from this attack for the foreseeable future.

To counter the use of large salt values and hash lengths, password crackers

exploit the fact that some people choose easily guessable passwords. A particular

problem is that users, when permitted to choose their own password, tend to choose

short ones. [BONN12] summarizes the results of a number of studies over the past

few years involving over 40 million hacked passwords, as well as their own analysis

of almost 70 million anonymized passwords of Yahoo! users, and found a tendency

toward six to eight characters of length and a strong dislike of non-alphanumeric

characters in passwords.

The analysis of the 70 million passwords in [BONN12] estimates that passwords

provide fewer than 10 bits of security against an online, trawling attack,

and only about 20 bits of security against an optimal offline dictionary attack. In

other words, an attacker who can manage 10 guesses per account, typically within

the realm of rate-limiting mechanisms, will compromise around 1% of accounts,

just as they would against random 10-bit strings. Against an optimal attacker

performing unrestricted brute force and wanting to break half of all available

accounts, passwords appear to be roughly equivalent to 20-bit random strings.

It can be seen then that using offline search enables an adversary to break

a large number of accounts, even if a significant amount of iterated hashing is

Used.

Password length is only part of the problem. Many people, when permitted

to choose their own password, pick a password that is guessable, such as their

own name, their street name, a common dictionary word, and so forth. This makes

the job of password cracking straightforward. The cracker simply has to test the

password file against lists of likely passwords. Because many people use guessable

passwords, such a strategy should succeed on virtually all systems.

Attacks that use a combination of brute-force and dictionary techniques have

become common. A notable example of this dual approach is John the Ripper, an

open-source password cracker first developed in 1996 and still in use [OPEN13].

Dictionary attacks

Develop a large dictionary of possible passwords and try each against the password file

Each password must be hashed using each salt value and then compared to stored hash values

Rainbow table attacks

Pre-compute tables of hash values for all salts

A mammoth table of hash values

Can be countered by using a sufficiently large salt value and a sufficiently large hash length

Password crackers exploit the fact that people choose easily guessable passwords

Shorter password lengths are also easier to crack

John the Ripper

Open-source password cracker first developed in in 1996

Uses a combination of brute-force and dictionary techniques

Modern Approaches

Complex password policy

Forcing users to pick stronger passwords

However password-cracking techniques have also improved

The processing capacity available for password cracking has increased dramatically

The use of sophisticated algorithms to generate potential passwords

Studying examples and structures of actual passwords in use

Sadly, this type of vulnerability has not lessened in

the past 25 years or so. Users are doing a better job of selecting passwords, and

organizations are doing a better job of forcing users to pick stronger passwords, a

concept known as a complex password policy, as discussed subsequently. However,

password-cracking techniques have improved to keep pace. The improvements

are of two kinds. First, the processing capacity available for password cracking has

increased dramatically. Now used increasingly for computing, graphics processors

allow password-cracking programs to work thousands of times faster than they did

just a decade ago on similarly priced PCs that used traditional CPUs alone. A PC

running a single AMD Radeon HD7970 GPU, for instance, can try on average an

8.2 * 109 password combinations each second, depending on the algorithm used

to scramble them [GOOD12a]. Only a decade ago, such speeds were possible only

when using pricey supercomputers.

The second area of improvement in password cracking is in the use of sophisticated

algorithms to generate potential passwords. For example, [NARA05] developed

a model for password generation using the probabilities of letters in natural language.

The researchers used standard Markov modeling techniques from natural language

processing to dramatically reduce the size of the password space to be searched.

But the best results have been achieved by studying examples of actual passwords

in use. To develop techniques that are more efficient and effective than simple

dictionary and brute-force attacks, researchers and hackers have studied the

structure of passwords. To do this, analysts need a large pool of real-word passwords

to study, which they now have. The first big breakthrough came in late 2009,

when an SQL injection attack against online games service RockYou.com exposed

32 million plaintext passwords used by its members to log in to their accounts

[TIMM10]. Since then, numerous sets of leaked password files have become available

for analysis.

Using large datasets of leaked passwords as training data, [WEIR09] reports

on the development of a probabilistic context-free grammar for password cracking.

In this approach, guesses are ordered according to their likelihood, based on

the frequency of their character-class structures in the training data, as well as the

frequency of their digit and symbol substrings. This approach has been shown to be

efficient in password cracking [KELL12, ZHAN10].

[MAZU13] reports on an analysis of the passwords used by over 25,000 students

at a research university with a complex password policy. The analysts used

the password-cracking approach introduced in [WEIR09]. They used a database

consisting of a collection of leaked password files, including the RockYou file.

Figure 3.4 summarizes a key result from the paper. The graph shows the percentage

of passwords that have been recovered as a function of the number of guesses. As

can be seen, over 10% of the passwords are recovered after only 1010 guesses. After

1013 guesses, almost 40% of the passwords are recovered.

Password File Access Control

One way to thwart a password attack is to deny the opponent access to the password

file. If the hashed password portion of the file is accessible only by a privileged user,

then the opponent cannot read it without already knowing the password of a privileged

user. Often, the hashed passwords are kept in a separate file from the user

IDs, referred to as a shadow password file. Special attention is paid to making the

shadow password file protected from unauthorized access. Although password file

protection is certainly worthwhile, there remain vulnerabilities:

• Many systems, including most UNIX systems, are susceptible to unanticipated

break-ins. A hacker may be able to exploit a software vulnerability in the

operating system to bypass the access control system long enough to extract

the password file. Alternatively, the hacker may find a weakness in the file

system or database management system that allows access to the file.

• An accident of protection might render the password file readable, thus compromising

all the accounts.

• Some of the users have accounts on other machines in other protection

domains, and they use the same password. Thus, if the passwords could

be read by anyone on one machine, a machine in another location might be

compromised.

• A lack of or weakness in physical security may provide opportunities for a

hacker. Sometimes there is a backup to the password file on an emergency

repair disk or archival disk. Access to this backup enables the attacker to read

the password file. Alternatively, a user may boot from a disk running another

operating system such as Linux and access the file from this OS.

• Instead of capturing the system password file, another approach to collecting

user IDs and passwords is through sniffing network traffic.

Thus, a password protection policy must complement access control measures with

techniques to force users to select passwords that are difficult to guess.

Can block offline guessing attacks by denying access to encrypted passwords

Make available only to privileged users

Shadow password file

Vulnerabilities

Weakness in the OS that allows access to the file

Accident with permissions making it readable

Users with same password on other systems

Access from backup media

Sniff passwords in network traffic

Password Selection Strategies

When not constrained, many users choose a password that is too short or too easy

to guess. At the other extreme, if users are assigned passwords consisting of eight

randomly selected printable characters, password cracking is effectively impossible.

But it would be almost as impossible for most users to remember their passwords.

Fortunately, even if we limit the password universe to strings of characters that are

reasonably memorable, the size of the universe is still too large to permit practical

cracking. Our goal, then, is to eliminate guessable passwords

while allowing the user to select a password that is memorable. Four basic techniques

are in use:

• User education

• Computer-generated passwords

• Reactive password checking

• Complex password policy

Users can be told the importance of using hard-to-guess passwords and can

be provided with guidelines for selecting strong passwords. This user education

strategy is unlikely to succeed at most installations, particularly where there is a large

user population or a lot of turnover. Many users will simply ignore the guidelines.

Others may not be good judges of what is a strong password. For example, many

users (mistakenly) believe that reversing a word or capitalizing the last letter makes

a password unguessable.

Nonetheless, it makes sense to provide users with guidelines on the selection

of passwords. Perhaps the best approach is the following advice: A good technique

for choosing a password is to use the first letter of each word of a phrase. However,

do not pick a well-known phrase like “An apple a day keeps the doctor away”

(Aaadktda). Instead, pick something like “My dog’s first name is Rex” (MdfniR)

or “My sister Peg is 24 years old” (MsPi24yo). Studies have shown that users can

generally remember such passwords but that they are not susceptible to password

guessing attacks based on commonly used passwords.

Computer-generated passwords also have problems. If the passwords are quite

random in nature, users will not be able to remember them. Even if the password

is pronounceable, the user may have difficulty remembering it and so be tempted

to write it down. In general, computer-generated password schemes have a history

of poor acceptance by users. FIPS 181 defines one of the best-designed automated

password generators. The standard includes not only a description of the approach

but also a complete listing of the C source code of the algorithm. The algorithm

generates words by forming pronounceable syllables and concatenating them to

form a word. A random number generator produces a random stream of characters

used to construct the syllables and words.

A reactive password checking strategy is one in which the system periodically

runs its own password cracker to find guessable passwords. The system cancels

any passwords that are guessed and notifies the user. This tactic has a number

of drawbacks. First, it is resource intensive if the job is done right. Because a

determined opponent who is able to steal a password file can devote full CPU

time to the task for hours or even days, an effective reactive password checker is

at a distinct disadvantage. Furthermore, any existing passwords remain vulnerable

until the reactive password checker finds them. A good example is the openware

Jack the Ripper password cracker (openwall.com/john/pro/), which works on a

variety of operating systems.

A promising approach to improved password security is a complex password

policy , or proactive password checker . In this scheme, a user is allowed to select his

or her own password. However, at the time of selection, the system checks to see if

the password is allowable and, if not, rejects it. Such checkers are based on the philosophy

that, with sufficient guidance from the system, users can select memorable

passwords from a fairly large password space that are not likely to be guessed in a

dictionary attack.

The trick with a proactive password checker is to strike a balance between

user acceptability and strength. If the system rejects too many passwords, users will

complain that it is too hard to select a password. If the system uses some simple

algorithm to define what is acceptable, this provides guidance to password crackers

to refine their guessing technique. In the remainder of this subsection, we look at

possible approaches to proactive password checking.

User education

Users can be told the importance of using hard to guess passwords and can be provided with guidelines for selecting strong passwords

Computer generated passwords

Users have trouble remembering them

Reactive password checking

System periodically runs its own password cracker to find guessable passwords

Complex password policy

User is allowed to select their own password, however the system checks to see if the password is allowable, and if not, rejects it

Goal is to eliminate guessable passwords while allowing the user to select a password that is memorable

Proactive Password Checking

Rule enforcement

Specific rules that passwords must adhere to

Password checker

Compile a large dictionary of passwords not to use

Bloom filter

Used to build a table based on hash values

Check desired password against this table

The first approach is a simple system for rule enforcement.

For example, NIST SP 800-63-2 suggests the following alternative rules:

• Password must have at least sixteen characters (basic16).

• Password must have at least eight characters including an uppercase and

lowercase letter, a symbol, and a digit. It may not contain a dictionary word

(comprehensive8).

Although NIST considers basic16 and comprehensive8 equivalent, [KELL12]

found that basic16 is superior against large numbers of guesses. Combined with a

prior result that basic16 is also easier for users [KOMA11], this suggests basic16 is

the better policy choice.

Although this approach is superior to simply educating users, it may not be sufficient

to thwart password crackers. This scheme alerts crackers as to which passwords

not to try, but may still make it possible to do password cracking.

The process of rule enforcement can be automated by using a proactive password

checker, such as the openware pam_passwdqc (openwall.com/passwdqc/), which

enforces a variety of rules on passwords and is configurable by the system administrator.

Another possible procedure is simply to compile a large dictionary

of possible “bad” passwords. When a user selects a password, the system

checks to make sure that it is not on the disapproved list. There are two problems

with this approach:

• Space: The dictionary must be very large to be effective.

• Time: The time required to search a large dictionary may itself be large. In addition,

to check for likely permutations of dictionary words, either those words

must be included in the dictionary, making it truly huge, or each search must

also involve considerable processing.

A technique [SPAF92a, SPAF92b] for developing an effective

and efficient proactive password checker that is based on rejecting words on a list

has been implemented on a number of systems, including Linux. It is based on the

use of a Bloom filter [BLOO70].

Figure 3.5 plots P as a function of R for various values of k. Suppose we have

a dictionary of 1 million words and we wish to have a 0.01 probability of rejecting a

password not in the dictionary. If we choose six hash functions, the required ratio

is R =9.6. Therefore, we need a hash table of 9.6 x106 bits or about 1.2 MBytes

of storage. In contrast, storage of the entire dictionary would require on the order

of 8 MBytes. Thus, we achieve a compression of almost a factor of 7. Furthermore,

password checking involves the straightforward calculation of six hash functions

and is independent of the size of the dictionary, whereas with the use of the full

dictionary, there is substantial searching.

Table 3.3

Types of Cards Used as Tokens

Objects that a user possesses for the purpose of user authentication are called

tokens. In this section, we examine two types of tokens that are widely used; these

are cards that have the appearance and size of bank cards (see Table 3.3).

Memory Cards

Can store but do not process data

The most common is the magnetic stripe card

Can include an internal electronic memory

Can be used alone for physical access

Hotel room

ATM

Provides significantly greater security when combined with a password or PIN

Drawbacks of memory cards include:

Requires a special reader

Loss of token

User dissatisfaction

Memory cards can store but not process data. The most common such card is the

bank card with a magnetic stripe on the back. A magnetic stripe can store only a

simple security code, which can be read (and unfortunately reprogrammed) by

an inexpensive card reader. There are also memory cards that include an internal

electronic memory.

Memory cards can be used alone for physical access, such as a hotel room. For

computer user authentication, such cards are typically used with some form of password

or personal identification number (PIN). A typical application is an automatic

teller machine (ATM). The memory card, when combined with a PIN or password, provides significantly

greater security than a password alone. An adversary must gain physical

possession of the card (or be able to duplicate it) plus must gain knowledge of the

PIN. Among the potential drawbacks NIST SP 800-12 (An Introduction to Computer

Security: The NIST Handbook , October 1995) notes the following:

• Requires special reader: This increases the cost of using the token and creates

the requirement to maintain the security of the reader’s hardware and software.

• Token loss: A lost token temporarily prevents its owner from gaining system

access. Thus there is an administrative cost in replacing the lost token. In addition,

if the token is found, stolen, or forged, then an adversary now need only

determine the PIN to gain unauthorized access.

• User dissatisfaction: Although users may have no difficulty in accepting the

use of a memory card for ATM access, its use for computer access may be

deemed inconvenient.

Smart Tokens

Physical characteristics:

Include an embedded microprocessor

A smart token that looks like a bank card

Can look like calculators, keys, small portable objects

User interface:

Manual interfaces include a keypad and display for human/token interaction

Electronic interface

A smart card or other token requires an electronic interface to communicate with a compatible reader/writer

Contact and contactless interfaces

Authentication protocol:

Classified into three categories:

Static

Dynamic password generator

Challenge-response

A wide variety of devices qualify as smart tokens. These can be categorized along

three dimensions that are not mutually exclusive:

• Physical characteristics: Smart tokens include an embedded microprocessor.

A smart token that looks like a bank card is called a smart card. Other smart

tokens can look like calculators, keys, or other small portable objects.

• User interface: Manual interfaces include a keypad and display for human/token

interaction.

Electronic interface: A smart card or other token requires an electronic interface

to communicate with a compatible reader/writer. A card may have one or

both of the following types of interface:

—— Contact: A contact smart card must be inserted into a smart card reader

with a direct connection to a conductive contact plate on the surface of the

card (typically gold plated). Transmission of commands, data, and card status

takes place over these physical contact points.

—— Contactless: A contactless card requires only close proximity to a reader.

Both the reader and the card have an antenna, and the two communicate

using radio frequencies. Most contactless cards also derive power for the

internal chip from this electromagnetic signal. The range is typically one-half

to three inches for non-battery-powered cards, ideal for applications such as

building entry and payment that require a very fast card interface.

• Authentication protocol: The purpose of a smart token is to provide a means

for user authentication. We can classify the authentication protocols used with

smart tokens into three categories:

— Static: With a static protocol, the user authenticates himself or herself

to the token and then the token authenticates the user to the computer.

The latter half of this protocol is similar to the operation of a memory

token.

— Dynamic password generator: In this case, the token generates a unique

password periodically (e.g., every minute). This password is then entered

into the computer system for authentication, either manually by the user or

electronically via the token. The token and the computer system must be

initialized and kept synchronized so that the computer knows the password

that is current for this token.

— Challenge-response: In this case, the computer system generates a challenge,

such as a random string of numbers. The smart token generates a response

based on the challenge. For example, public-key cryptography could be used

and the token could encrypt the challenge string with the token’s private key.

Smart Cards

Most important category of smart token

Has the appearance of a credit card

Has an electronic interface

May use any of the smart token protocols

Contain:

An entire microprocessor

Processor

Memory

I/O ports

Typically include three types of memory:

Read-only memory (ROM)

Stores data that does not change during the card’s life

Electrically erasable programmable ROM (EEPROM)

Holds application data and programs

Random access memory (RAM)

Holds temporary data generated when applications are executed

For user authentication the most important category of smart token is the

smart card, which has the appearance of a credit card, has an electronic interface,

and may use any of the type of protocols just described. The remainder of this

section discusses smart cards.

A smart card contains within it an entire microprocessor, including processor,

memory, and I/O ports. Some versions incorporate a special co-processing circuit for

cryptographic operation to speed the task of encoding and decoding messages or generating

digital signatures to validate the information transferred. In some cards, the

I/O ports are directly accessible by a compatible reader by means of exposed

electrical contacts. Other cards rely instead on an embedded antenna for wireless communication

with the reader.

A typical smart card includes three types of memory. Read-only memory

(ROM) stores data that does not change during the card’s life, such as the card

number and the cardholder’s name. Electrically erasable programmable ROM

(EEPROM) holds application data and programs, such as the protocols that the

card can execute. It also holds data that may vary with time. For example, in a

telephone card, the EEPROM holds the talk time remaining. Random access

memory (RAM) holds temporary data generated when applications are executed.

Figure 3.6 illustrates the typical interaction between a smart card and a

reader or computer system. Each time the card is inserted into a reader, a reset is

initiated by the reader to initialize parameters such as clock value. After the reset

function is performed, the card responds with answer to reset (ATR) message.

This message defines the parameters and protocols that the card can use and the

functions it can perform. The terminal may be able to change the protocol used

and other parameters via a protocol type selection (PTS) command. The cards

PTS response confirms the protocols and parameters to be used. The terminal

and card can now execute the protocol to perform the desired application.

Electronic Identity Cards (eID)

An application of increasing importance is the use of a smart card as a national identity

card for citizens. A national electronic identity (eID) card can serve the same purposes

as other national ID cards, and similar cards such as a driver’s license, for access

to government and commercial services. In addition, an eID card can provide stronger

proof of identity and be used in a wider variety of applications. In effect, an eID card is

a smart card that has been verified by the national government as valid and authentic.

One of the most recent and most advanced eID deployments is the German

eID card neuer Personalausweis [POLL12]. The card has human-readable data

printed on its surface, including the following:

• Personal data: Such as name, date of birth, and address; this is the type of

printed information found on passports and driver’s licenses.

• Document number: An alphanumerical nine-character unique identifier of

each card.

• Card access number (CAN): A six-digit decimal random number printed on

the face of the card. This is used as a password, as explained subsequently.

• Machine readable zone (MRZ): Three lines of human- and machine-readable

text on the back of the card. This may also be used as a password.

Use of a smart card as a national identity card for citizens

Can serve the same purposes as other national ID cards, and similar cards such as a driver’s license, for access to government and commercial services

Can provide stronger proof of identity and can be used in a wider variety of applications

In effect, is a smart card that has been verified by the national government as valid and authentic

Most advanced deployment is the German card neuer Personalausweis

Has human-readable data printed on its surface

Personal data

Document number

Card access number (CAN)

Machine readable zone (MRZ)

Table 3.4 Electronic Functions and Data for eID Cards

CAN = card access number

MRZ = machine readable zone

PACE = password authenticated connection establishment

PIN = personal identification number

The card has the following three separate electronic functions,

each with its own protected dataset (Table 3.4):

• ePass: This function is reserved for government use and stores a digital representation

of the cardholder’s identity. This function is similar to, and may

be used for, an electronic passport. Other government services may also use

ePass. The ePass function must be implemented on the card.

• eID: This function is for general-purpose use in a variety of government and

commercial applications. The eID function stores an identity record that

authorized service can access with cardholder permission. Citizens choose

whether they want this function activated.

• eSign: This optional function stores a private key and a certificate verifying the

key; it is used for generating a digital signature. A private sector trust center

issues the certificate.

The ePass function is an offline function. That is, it is not used over a network

but is used in a situation where the cardholder presents the card for a particular

service at that location, such as going through a passport control checkpoint.

The eID function can be used for both online and offline services. An example

of an offline use is an inspection system. An inspection system is a terminal for law

enforcement checks, for example, by police or border control officers. An inspection

system can read identifying information of the cardholder as well as biometric

information stored on the card, such as facial image and fingerprints. The biometric

information can be used to verify that the individual in possession of the card is the

actual cardholder.

User authentication is a good example of online use of the eID function.

Figure 3.7 illustrates a Web-based scenario. To begin, an eID user visits a Web

site and requests a service that requires authentication. The Web site sends back

a redirect message that forwards an authentication request to an eID server. The

eID server requests that the user enter the PIN number for the eID card. Once the

user has correctly entered the PIN, data can be exchanged between the eID card

and the terminal reader in encrypted form. The server then engages in an authentication

protocol exchange with the microprocessor on the eID card. If the user is

authenticated the results are sent back to the user system to be redirected to the

Web server application.

For the preceding scenario, the appropriate software and hardware are

required on the user system. Software on the main user system includes functionality

for requesting and accepting the PIN number and for message redirection.

The hardware required is an eID card reader. The card reader can be an external

contact or contactless reader or a contactless reader internal to the user system.

Password Authenticated Connection Establishment (PACE)

Password Authenticated Connection Establishment (PACE) ensures that the contactless

RF chip in the eID card cannot be read without explicit access control. For online

applications, access to the card is established by the user entering the 6-digit PIN,

which should only be known to the holder of the card. For offline applications,

either the MRZ printed on the back of the card or the six-digit card access number

(CAN) printed on the front is used.

Ensures that the contactless RF chip in the eID card cannot be read without explicit access control

For online applications, access is established by the user entering the 6-digit PIN (which should only be known to the holder of the card)

For offline applications, either the MRZ printed on the back of the card or the six-digit card access number (CAN) printed on the front is used

Biometric Authentication

Attempts to authenticate an individual based on unique physical characteristics

Based on pattern recognition

Is technically complex and expensive when compared to passwords and tokens

Physical characteristics used include:

Facial characteristics

Fingerprints

Hand geometry

Retinal pattern

Iris

Signature

Voice

A biometric authentication system attempts to authenticate an individual based on

his or her unique physical characteristics. These include static characteristics, such

as fingerprints, hand geometry, facial characteristics, and retinal and iris patterns;

and dynamic characteristics, such as voiceprint and signature. In essence, biometrics

is based on pattern recognition. Compared to passwords and tokens, biometric

authentication is both technically complex and expensive. While it is used in a

number of specific applications, biometrics has yet to mature as a standard tool for

user authentication to computer systems.

A number of different types of physical characteristics are either in use or under

study for user authentication. The most common are the following:

• Facial characteristics: Facial characteristics are the most common means

of human-to-human identification; thus it is natural to consider them for

identification by computer. The most common approach is to define characteristics

based on relative location and shape of key facial features, such as

eyes, eyebrows, nose, lips, and chin shape. An alternative approach is to use an

infrared camera to produce a face thermogram that correlates with the underlying

vascular system in the human face.

• Fingerprints: Fingerprints have been used as a means of identification for

centuries, and the process has been systematized and automated particularly

for law enforcement purposes. A fingerprint is the pattern of ridges and

furrows on the surface of the fingertip. Fingerprints are believed to be unique

across the entire human population. In practice, automated fingerprint recognition

and matching system extract a number of features from the fingerprint

for storage as a numerical surrogate for the full fingerprint pattern.

• Hand geometry: Hand geometry systems identify features of the hand,

including shape, and lengths and widths of fingers.

• Retinal pattern: The pattern formed by veins beneath the retinal surface is

unique and therefore suitable for identification. A retinal biometric system

obtains a digital image of the retinal pattern by projecting a low-intensity

beam of visual or infrared light into the eye.

• Iris: Another unique physical characteristic is the detailed structure of the iris.

• Signature: Each individual has a unique style of handwriting and this is

reflected especially in the signature, which is typically a frequently written

sequence. However, multiple signature samples from a single individual will

not be identical. This complicates the task of developing a computer representation

of the signature that can be matched to future samples.

• Voice: Whereas the signature style of an individual reflects not only the unique

physical attributes of the writer but also the writing habit that has developed,

voice patterns are more closely tied to the physical and anatomical characteristics

of the speaker. Nevertheless, there is still a variation from sample to sample over

time from the same speaker, complicating the biometric recognition task.

Figure 3.8 gives a rough indication of the relative cost and accuracy of these

biometric measures. The concept of accuracy does not apply to user authentication

schemes using smart cards or passwords. For example, if a user enters a password,

it either matches exactly the password expected for that user or not. In the case of

biometric parameters, the system instead must determine how closely a presented

biometric characteristic matches a stored characteristic. Before elaborating on the

concept of biometric accuracy, we need to have a general idea of how biometric

systems work.

Figure 3.9 illustrates the operation of a biometric system. Each individual who is to be

included in the database of authorized users must first be enrolled in the system. This

is analogous to assigning a password to a user. For a biometric system, the user presents

a name and, typically, some type of password or PIN to the system. At the same

time the system senses some biometric characteristic of this user (e.g., fingerprint of

right index finger). The system digitizes the input and then extracts a set of features

that can be stored as a number or set of numbers representing this unique biometric

characteristic; this set of numbers is referred to as the user’s template. The user is now

enrolled in the system, which maintains for the user a name (ID), perhaps a PIN or

password, and the biometric value.

Depending on application, user authentication on a biometric system involves

either verification or identification. Verification is analogous to a user logging on

to a system by using a memory card or smart card coupled with a password or PIN.

For biometric verification, the user enters a PIN and also uses a biometric sensor.

The system extracts the corresponding feature and compares that to the template

stored for this user. If there is a match, then the system authenticates this user.

For an identification system, the individual uses the biometric sensor but

presents no additional information. The system then compares the presented

template with the set of stored templates. If there is a match, then this user is

identified. Otherwise, the user is rejected.

In any biometric scheme, some physical characteristic of the individual is mapped into a

digital representation. For each individual, a single digital representation, or template, is

stored in the computer. When the user is to be authenticated, the system

compares the stored template to the presented template. Given the complexities of physical characteristics,

we cannot expect that there will be an exact match between the two templates.

Rather, the system uses an algorithm to generate a matching score (typically a single

number) that quantifies the similarity between the input and the stored template. To

proceed with the discussion, we define the following terms. The false match rate is the

frequency with which biometric samples from different sources are erroneously assessed

to be from the same source. The false nonmatch rate is the frequency with which samples

from the same source are erroneously assessed to be from different sources.

Figure 3.10 illustrates the dilemma posed to the system. If a single user is tested

by the system numerous times, the matching score s will vary, with a probability

density function typically forming a bell curve, as shown. For example, in the case of

a fingerprint, results may vary due to sensor noise; changes in the print due to swelling,

dryness, and so on; finger placement; and so on. On average, any other individual

should have a much lower matching score but again will exhibit a bell-shaped probability

density function. The difficulty is that the range of matching scores produced

by two individuals, one genuine and one an imposter, compared to a given reference

template, are likely to overlap. In Figure 3.10 a threshold value is selected thus that if

the presented value s ≥ t a match is assumed, and for s < t, a mismatch is assumed.

The shaded part to the right of t indicates a range of values for which a false match is

possible, and the shaded part to the left indicates a range of values for which a false

nonmatch is possible. The area of each shaded part represents the probability of a

false match or nonmatch, respectively. By moving the threshold, left or right, the

probabilities can be altered, but note that a decrease in false match rate necessarily

results in an increase in false nonmatch rate, and vice versa.

For a given biometric scheme, we can plot the false match versus false nonmatch

rate, called the operating characteristic curve. Figure 3.11 shows idealized curves for

two different systems. The curve that is lower and to the left performs better. The

dot on the curve corresponds to a specific threshold for biometric testing. Shifting the

threshold along the curve up and to the left provides greater security and the cost of

decreased convenience. The inconvenience comes from a valid user being denied access

and being required to take further steps. A plausible tradeoff is to pick a threshold that

corresponds to a point on the curve where the rates are equal. A high-security application

may require a very low false match rate, resulting in a point farther to the left on the

curve. For a forensic application, in which the system is looking for possible candidates,

to be checked further, the requirement may be for a low false nonmatch rate.

Figure 3.12 shows characteristic curves developed from actual product testing.

The iris system had no false matches in over 2 million cross-comparisons. Note that

over a broad range of false match rates, the face biometric is the worst performer.

Remote User Authentication

Authentication over a network, the Internet, or a communications link is more complex

Additional security threats such as:

Eavesdropping, capturing a password, replaying an authentication sequence that has been observed

Generally rely on some form of a challenge-response protocol to counter threats

The simplest form of user authentication is local authentication, in which a user

attempts to access a system that is locally present, such as a stand-alone office PC or

an ATM machine. The more complex case is that of remote user authentication,

which takes place over the Internet, a network, or a communications link. Remote

user authentication raises additional security threats, such as an eavesdropper being

able to capture a password, or an adversary replaying an authentication sequence

that has been observed.

To counter threats to remote user authentication, systems generally rely on some

form of challenge-response protocol. In this section, we present the basic elements of

such protocols for each of the types of authenticators discussed in this chapter.

Figure 3.13a provides a simple example of a challenge-response protocol for

authentication via password. Actual protocols are more complex, such as Kerberos,

discussed in Chapter 23. In this example, a user first transmits his or her identity to

the remote host. The host generates a random number r, often called a nonce, and

returns this nonce to the user. In addition, the host specifies two functions, h() and

f(), to be used in the response. This transmission from host to user is the challenge.

The user’s response is the quantity f(r’, h(P’)), where r’ = r and P’ is the user’s

password. The function h is a hash function, so that the response consists of the

hash function of the user’s password combined with the random number using the

function f.

The host stores the hash function of each register user’s password, depicted

as h(P(U)) for user U. When the response arrives, the host compares the incoming

f(r’, h(P’)) to the calculated f(r, h(P(U))). If the quantities match, the user is

authenticated.

This scheme defends against several forms of attack. The host stores not the

password but a hash code of the password. As discussed in Section 3.2, this secures

the password from intruders into the host system. In addition, not even the hash of

the password is transmitted directly, but rather a function in which the password hash

is one of the arguments. Thus, for a suitable function f, the password hash cannot be

captured during transmission. Finally, the use of a random number as one of the arguments

of f defends against a replay attack, in which an adversary captures the user’s

transmission and attempts to log on to a system by retransmitting the user’s messages.

Figure 3.13b provides a simple example of a token protocol for authentication.

As before, a user first transmits his or her identity to the remote host. The host

returns a random number and the identifiers of functions f() and h() to be used in the

response. At the user end, the token provides a passcode W’. The token either stores

a static passcode or generates a one-time random passcode. For a one-time random

passcode, the token must be synchronized in some fashion with the host. In either

case, the user activates the passcode by entering a password P’. This password is

shared only between the user and the token and does not involve the remote

host. The token responds to the host with the quantity f(r’, h(W’ )). For a static passcode,

the host stores the hashed value h(W (U )); for a dynamic passcode, the host generates

a one-time passcode (synchronized to that generated by the token) and takes its hash.

Authentication then proceeds in the same fashion as for the password protocol.

Figure 3.13c is an example of a user authentication protocol using a static biometric.

As before, the user transmits an ID to the host, which responds with a random number

r and, in this case, the identifier for an encryption E(). On the user side is a client system

that controls a biometric device. The system generates a biometric template BT’

from the user’s biometric B’ and returns the ciphertext E(r’, D’, BT’) , where D’

identifies this particular biometric device. The host decrypts the incoming

message to recover the three transmitted parameters and compares these to locally stored values.

For a match, the host must find r’ = r . Also, the matching score between BT’ and

the stored template must exceed a predefined threshold. Finally, the host provides

a simple authentication of the biometric capture device by comparing the incoming

device ID to a list of registered devices at the host database.

Figure 3.13d is an example of a user authentication protocol using a dynamic

biometric. The principal difference from the case of a stable biometric is that the

host provides a random sequence as well as a random number as a challenge. The

sequence challenge is a sequence of numbers, characters, or words. The human

user at the client end must then vocalize (speaker verification), type (keyboard

dynamics verification), or write (handwriting verification) the sequence to generate

a biometric signal BS’ (x’) . The client side encrypts the biometric signal and

the random number. At the host side, the incoming message is decrypted. The

incoming random number r’ must be an exact match to the random number that

was originally used as a challenge (r ). In addition, the host generates a comparison

based on the incoming biometric signal BS’ (x’) , the stored template

BT (U ) for this user and the original signal x . If the comparison value exceeds

a predefined threshold, the user is authenticated.

Table 3.5

Some Potential

Attacks,

Susceptible Authenticators,

and

Typical Defenses

(Table is on page 96 in the textbook)

As with any security service, user authentication, particularly remote user authentication,

is subject to a variety of attacks. Table 3.5, from [OGOR03], summarizes

the principal attacks on user authentication, broken down by type of authenticator.

Much of the table is self-explanatory. In this section, we expand on some of the

table’s entries.

Client attacks are those in which an adversary attempts to achieve user

authentication without access to the remote host or to the intervening communications

path. The adversary attempts to masquerade as a legitimate user. For a password-

based system, the adversary may attempt to guess the likely user password.

Multiple guesses may be made. At the extreme, the adversary sequences through

all possible passwords in an exhaustive attempt to succeed. One way to thwart such

an attack is to select a password that is both lengthy and unpredictable. In effect,

such a password has large entropy; that is, many bits are required to represent the

password. Another countermeasure is to limit the number of attempts that can be

made in a given time period from a given source.

A token can generate a high-entropy passcode from a low-entropy PIN or password,

thwarting exhaustive searches. The adversary may be able to guess or acquire

the PIN or password but must additionally acquire the physical token to succeed.

Host attacks are directed at the user file at the host where passwords, token

passcodes, or biometric templates are stored. Section 3.2 discusses the security

considerations with respect to passwords. For tokens, there is the additional

defense of using one-time passcodes, so that passcodes are not stored in a host

passcode file. Biometric features of a user are difficult to secure because they are

physical features of the user. For a static feature, biometric device authentication

adds a measure of protection. For a dynamic feature, a challenge-response

protocol enhances security.

Eavesdropping in the context of passwords refers to an adversary’s attempt to

learn the password by observing the user, finding a written copy of the password,

or some similar attack that involves the physical proximity of user and adversary.

Another form of eavesdropping is keystroke logging (keylogging), in which malicious

hardware or software is installed so that the attacker can capture the user’s keystrokes

for later analysis. A system that relies on multiple factors (e.g., password plus token or

password plus biometric) is resistant to this type of attack. For a token, an analogous

threat is theft of the token or physical copying of the token. Again, a multifactor

protocol resists this type of attack better than a pure token protocol. The analogous

threat for a biometric protocol is copying or imitating the biometric

parameter so as to generate the desired template. Dynamic biometrics are less susceptible

to such attacks. For static biometrics, device authentication is a useful countermeasure.

Replay attacks involve an adversary repeating a previously captured

user response. The most common countermeasure to such attacks is the challenge-response

protocol.

In a Trojan horse attack, an application or physical device masquerades as

an authentic application or device for the purpose of capturing a user password,

passcode, or biometric. The adversary can then use the captured information to

masquerade as a legitimate user. A simple example of this is a rogue bank machine

used to capture user ID/password combinations.

A denial-of-service attack attempts to disable a user authentication service by

flooding the service with numerous authentication attempts. A more selective attack

denies service to a specific user by attempting logon until the threshold is reached

that causes lockout to this user because of too many logon attempts. A multifactor

authentication protocol that includes a token thwarts this attack, because the

adversary must first acquire the token.

Authentication Security Issues

Eavesdropping

Adversary attempts to learn the password by some sort of attack that involves the physical proximity of user and adversary

Host Attacks

Directed at the user file at the host where passwords, token passcodes, or biometric templates are stored

Replay

Adversary repeats a previously captured user response

Client Attacks

Adversary attempts to achieve user authentication without access to the remote host or the intervening communications path

Trojan Horse An application or physical device masquerades as an authentic application or device for the purpose of capturing a user password, passcode, or biometric

Denial-of-Service

Attempts to disable a user authentication service by flooding the service with numerous authentication attempts

As an example of a biometric user authentication system, we look at an iris biometric

system that was developed for use by the United Arab Emirates (UAE) at

border control points [DAUG04, TIRO05, NBSP08]. The UAE relies heavily on an

outside workforce, and has increasingly become a tourist attraction. Accordingly,

relative to its size, the UAE has a very substantial volume of incoming visitors. On

a typical day, more than 6,500 passengers enter the UAE via seven international

airports, three land ports, and seven sea ports. Handling a large volume of incoming

visitors in an efficient and timely manner thus poses a significant security challenge.

Of particular concern to the UAE are attempts by expelled persons to re-enter the

country. Traditional means of preventing reentry involve identifying individuals by

name, date of birth, and other text-based data. The risk is that this information can

be changed after expulsion. An individual can arrive with a different passport with a

different nationality and changes to other identifying information.

To counter such attempts, the UAE decided on using a biometric identification

system and identified the following requirements:

• Identify a single person from a large population of people

• Rely on a biometric feature that does not change over time

• Use biometric features that can be acquired quickly

• Be easy to use

• Respond in real-time for mass transit applications

• Be safe and non-invasive

• Scale into the billions of comparisons and maintain top performance

• Be affordable

Iris recognition was chosen as the most efficient and foolproof method. No two irises

are alike. There is no correlation between the iris patterns of even identical twins, or

the right and left eye of an individual.

System implementation involves enrollment and identity checking. All

expelled foreigners are subjected to an iris scan at one of the multiple enrollment

centers. This information is merged into one central database. Iris scanners are

installed at all 17 air, land, and sea ports into the UAE. An iris-recognition camera

takes a black-and-white picture 5 to 24 inches from the eye, depending on the

camera. The camera uses non-invasive, near-infrared illumination that is similar

to a TV remote control, barely visible and considered extremely safe. The picture

first is processed by software that localizes the inner and outer boundaries of the

iris, and the eyelid contours, in order to extract just the iris portion. The software

creates a so-called phase code for the texture of the iris, similar to a DNA sequence

code. The unique features of the iris are captured by this code and can be compared

against a large database of scanned irises to make a match. Over a distributed network

(Figure 3.14) the iris codes of all arriving passengers are compared in real-time

exhaustively against an enrolled central database.

Note that this is computationally a more demanding task than verifying an

identity. In this case, the iris pattern of each incoming passenger is compared against

the entire database of known patterns to determine if there is a match. Given the

current volume of traffic and size of the database, the daily number of iris cross-comparisons

is well over 9 billion.

As with any security system, adversaries are always looking for countermeasures.

UAE officials had to adopt new security methods to detect if an iris has been

dilated with eye drops before scanning. Expatriates who were banned from the

UAE started using eye drops in an effort to fool the government’s iris recognition

system when they try to re-enter the country. A new algorithm and computerized

step-by-step procedure has been adopted to help officials determine if an iris is in

normal condition or an eye-dilating drop has been used.

Case Study: ATM Security Problems

Redspin, Inc., an independent auditor, recently released a report describing a

security vulnerability in ATM (automated teller machine) usage that affects a

number of small to mid-size ATM card issuers. This vulnerability provides a useful

case study illustrating that cryptographic functions and services alone do not

guarantee security; they must be properly implemented as part of a system.

We begin by defining terms used in this section:

• Cardholder: An individual to whom a debit card is issued. Typically, this

individual is also responsible for payment of all charges made to that card.

• Issuer: An institution that issues debit cards to cardholders. This institution

is responsible for the cardholder’s account and authorizes all transactions.

Banks and credit unions are typical issuers.

• Processor: An organization that provides services such as core data processing

(PIN recognition and account updating), electronic funds transfer (EFT), and so

on to issuers. EFT allows an issuer to access regional and national networks that

connect point of sale (POS) devices and ATMs worldwide. Examples of processing

companies include Fidelity National Financial and Jack Henry & Associates.

Customers expect 24/7 service at ATM stations. For many small to mid-sized

issuers, it is more cost-effective for contract processors to provide the required data

processing and EFT/ATM services. Each service typically requires a dedicated data

connection between the issuer and the processor, using a leased line or a virtual

leased line.

Prior to about 2003, the typical configuration involving issuer, processor,

and ATM machines could be characterized by Figure 3.15a. The ATM units linked

directly to the processor rather than to the issuer that owned the ATM, via leased

or virtual leased line. The use of a dedicated link made it difficult to maliciously

intercept transferred data. To add to the security, the PIN portion of messages

transmitted from ATM to processor was encrypted using DES (Data Encryption

Standard). Processors have connections to EFT (electronic funds transfer) exchange

networks to allow cardholders access to accounts from any ATM. With the configuration

of Figure 3.15a, a transaction proceeds as follows. A user swipes her card and

enters her PIN. The ATM encrypts the PIN and transmits it to the processor as part

of an authorization request. The processor updates the customer’s information and

sends a reply.

In the early 2000s, banks worldwide began the process of migrating from

an older generation of ATMs using IBM’s OS/2 operating system to new systems

running Windows. The mass migration to Windows has been spurred by a number

of factors, including IBM’s decision to stop supporting OS/2 by 2006, market

pressure from creditors such as MasterCard International and Visa International to

introduce stronger Triple DES, and pressure from U.S. regulators to introduce new

features for disabled users. Many banks, such as those audited by Redspin, included

a number of other enhancements at the same time as the introduction of Windows

and triple DES, especially the use of TCP/IP as a network transport.

Because issuers typically run their own Internet-connected local area networks

(LANs) and intranets using TCP/IP, it was attractive to connect ATMs to these

issuer networks and maintain only a single dedicated line to the processor, leading

to the configuration illustrated in Figure 3.15b. This configuration saves the issuer

expensive monthly circuit fees and enables easier management of ATMs by the

issuer. In this configuration, the information sent from the ATM to the processor

traverses the issuer’s network before being sent to the processor. It is during this

time on the issuer’s network that the customer information is vulnerable.

The security problem was that with the upgrade to a new ATM OS and a

new communications configuration, the only security enhancement was the use of

triple DES rather than DES to encrypt the PIN. The rest of the information in the

ATM request message is sent in the clear. This includes the card number, expiration

date, account balances, and withdrawal amounts. A hacker tapping into the bank’s

network, either from an internal location or from across the Internet potentially

would have complete access to every single ATM transaction.

The situation just described leads to two principal vulnerabilities:

• Confidentiality: The card number, expiration date, and account balance can

be used for online purchases or to create a duplicate card for signature-based

transactions.

• Integrity: There is no protection to prevent an attacker from injecting or

altering data in transit. If an adversary is able to capture messages en route,

the adversary can masquerade as either the processor or the ATM. Acting

as the processor, the adversary may be able to direct the ATM to dispense

money without the processor ever knowing that a transaction has occurred.

If an adversary captures a user’s account information and encrypted PIN,

the account is compromised until the ATM encryption key is changed,

enabling the adversary to modify account balances or effect transfers.

Redspin recommended a number of measures that banks can take to counter

these threats. Short-term fixes include segmenting ATM traffic from the rest of the

network either by implementing strict firewall rule sets or physically dividing the

networks altogether. An additional short-term fix is to implement network-level

encryption between routers that the ATM traffic traverses.

Long-term fixes involve changes in the application-level software. Protecting

confidentiality requires encrypting all customer-related information that traverses

the network. Ensuring data integrity requires better machine-to-machine authentication

between the ATM and processor and the use of challenge-response protocols

to counter replay attacks.

Summary

Biometric authentication

Physical characteristics used in biometric applications

Operation of a biometric authentication system

Biometric accuracy

Remote user authentication

Password protocol

Token protocol

Static biometric protocol

Dynamic biometric protocol

Security issues for user authentication

Digital user authentication principles

A model for digital user authentication

Means of authentication

Risk assessment for user authentication

Password-based authentication

The vulnerability of passwords

The use of hashed passwords

Password cracking of user-chosen passwords

Password file access control

Password selection strategies

Token-based authentication

Memory cards

Smart cards

Electronic identity cards

Chapter 3 summary.

Table 3.1 Identification and Authentication Security Requirements ( SP 800-171)

Basic Security Requirements: 1 Identify information system users, processes acting on behalf of users, or devices. 2 Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite

to allowing access to organizational information systems.

Derived Security Requirements: 3 Use multifactor authentication for local and network access to privileged accounts and for

network access to non-privileged accounts. 4 Employ replay-resistant authentication mechanisms for network access to privileged and

non-privileged accounts. 5 Prevent reuse of identifiers for a defined period. 6 Disable identifiers after a defined period of inactivity. 7 Enforce a minimum password complexity and change of characters when new passwords

are created. 8 Prohibit password reuse for a specified number of generations. 9 Allow temporary password use for system logons with an immediate change to a

permanent password. 10 Store and transmit only cryptographically-protected passwords. 11 Obscure feedback of authentication information.

Table 3.1 Identification and Authentication Security Requirements ( SP 800-171)

Basic Security Requirements:

1 Identify information system users, processes acting on behalf of users, or devices.

2 Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite

to allowing access to organizational information systems.

Derived Security Requirements:

3 Use multifactor authentication for local and network access to privileged accounts and for

network access to non-privileged accounts.

4 Employ replay-resistant authentication mechanisms for network access to privileged and

non-privileged accounts.

5 Prevent reuse of identifiers for a defined period.

6 Disable identifiers after a defined period of inactivity.

7 Enforce a minimum password complexity and change of characters when new passwords

are created.

8 Prohibit password reuse for a specified number of generations.

9 Allow temporary password use for system logons with an immediate change to a

permanent password.

10 Store and transmit only cryptographically-protected passwords.

11 Obscure feedback of authentication information.

Figure 3.1 The NIST SP 800-63-2 E-Authentication Architectural Model

Registration Authority (RA)

Registration, Credential Issuance, and Maintenance

E-Authentication using Token and Credential

Identity Proofing User Registration

To ke

n, Cr

ed en

tia l

Re gis

tra tio

n/I ssu

an ce

Authenticated Session

Authenticated Protocol

Exchange

Authenticated Assertion

Registration Confirmation

Token/Credential Validation

Relying Party (RP)

Verifier

Subscriber/ Claimant

Credential Service

Provider (RA)

Figure 3.1 The NIST SP 800-63-2 E-Authentication Architectural Model

Registration

Authority (RA)

Registration, Cr edential Issuance,

and Maintenance

E-Authentication using

Token and Credential

Identity Proofing

User Registration

Authenticated Session

Authenticated

Assertion

Registration

Confirmation

Token/Credential

Validation

Relying

Party (RP)

Verifier

Subscriber/

Claimant

Credential

Service

Provider (RA)

Figure 3.2 Multifactor Authentication

Client Client

Au th

en tic

at ion

pr ot

oc ol

Authentication logic using first factor

Pass

Fail

Au th

en tic

at ion

pr ot

oc ol

Authentication logic using

second factor

Pass

Fail

Figure 3.2 Multifactor Authentication

Client Client

Authentication

logic using

frst factor

Pass

Fail

Authentication

logic using

second factor

Pass

Fail

Potential Impact Categories for Authentication Errors Inconvenience, distress, or damage to standing or reputation Financial loss or organization liability Harm to organization programs or interests Unauthorized release of sensitive information Personal safety Civil or criminal violations

Potential Impact Categories for Authentication Errors

Inconvenience, distress, or damage to standing or

reputation

Financial loss or organization liability

Harm to organization programs or interests

Unauthorized release of sensitive information

Personal safety

Civil or criminal violations

Assurance Level Impact Profiles 1 2 3 4

Low Mod Mod High Low Mod Mod High None Low Mod High None Low Mod High

None None Low Mod/ High None Low Mod High

Assurance Level Impact Profiles

1 2 3 4

Low Mod Mod High

None Low Mod High

None None Low

Mod/

High

None Low Mod High

User ID Salt

Password

Load

Select

(a) Loading a new password

(b) Verifying a password

Figure 3.3 UNIX Password Scheme

Salt

• • •

Password File

Hash code

User ID User id

Salt

Password File

slow hash function

Salt

Hashed password

Password

slow hash function

Compare

Hash code

User ID

Salt

Password

Load

Select

(a) Loading a new password

(b) Verifying a password

Figure 3.3 UNIX Password Scheme

Salt

•

Password File

Hash code

User ID

User id

Salt

Password File

slow hash

function

Salt

Hashed password

Password

slow hash

function

Compare

Hash code

Figure 3.4 The Percentage of Passwords Guessed After a Given Number of Guesses

0% 104 107 1010 1013

10%

P er

ce nt

g ue

ss ed

Number of guesses

20%

30%

40%

50%

Figure 3.4 The Percentage of Passwords Guessed After

a Given Number of Guesses

10%

Number of guesses

20%

30%

40%

50%

0.001

0.01

0.1

1 Pr

[f al

se p

os iti

ve ]

20151050

Ratio of hash table size (bits) to dictionary size (words)

Figure 3.5 Performance of Bloom Filter

4 hash functions

2 hash functions

6 hash functions

0.001

0.01

0.1

[

]

20151050

Ratio of hash table size (bits) to dictionary size (words)

Figure 3.5 Performance of Bloom Filter

4 hash functions

2 hash functions

6 hash functions

Card Type Defining Feature Example Embossed Raised characters only, on

front Old credit card

Magnetic stripe Magnetic bar on back, characters on front Bank card Memory Electronic memory inside Prepaid phone card

Smart Contact Contactless

Electronic memory and processor inside Electrical contacts exposed on surface Radio antenna embedded inside

Biometric ID card

Card Type Defining Feature Example

Embossed Raised characters only, on

front

Old credit card

Magnetic stripe Magnetic bar on back, characters on front Bank card

Memory Electronic memory inside Prepaid phone card

Smart

Contact

Contactless

Electronic memory and processor inside

Electrical contacts exposed on surface

Radio antenna embedded inside

Biometric ID card

Function	Purpose	PACE Password	Data	Uses
ePass (mandatory)	Authorized offline inspection systems read the data	CAN or MRZ	Face image; two fingerprint images (optional), MRZ data	Offline biometric identity verification reserved for government access
eID (activation optional	Online applications read the data or acess functions as authorized	eID PIN	Family and given names; artistic name and doctoral degree: date and place of birth; address and community ID; expiration date	Identification; age verification; community ID verification; restricted identification (pseudonym); revocation query
	Offline inspection systems read the data and update the address and community ID	CAN or MRZ
eSign (certificate optional	A certification authority installs the signature certificate online	eID PIN	Signature key; X.509 certificate	Electronic signature creation
	Citizens make electronic signature with eSign PIN	CAN

Figure 3.7 User Authentication with eID

eID

server

Host/application

server

6. User enters PIN

1. User requests service (e.g., via Web browser)

4. A uth

ent ica

tio n r

equ est

5. P IN

re qu

est

7. A uth

ent ica

tio n p

rot oco

l ex cha

ng e

8. A uth

ent ica

tio n r

esu lt f

or red

ire ct

2. Service request3. Redirect to eID message

9. Authentication result forwarded

10. Service granted

Figure 3.7 User Authentication with eID

eID

server

Host/application

server

6. User enters PIN

1. User requests service

(e.g., via Web browser)

Hand

Signature

Face

Voice

Retina

Finger

Accuracy

C os

Iris

Figure 3.8 Cost Versus Accuracy of Various Biometric Characteristics in User Authentication Schemes.

Biometric

sensor Biometric

database

Name (PIN)

User interface

(a) Enrollment

Feature

extractor

Biometric

sensor

Name (PIN)

User interface

(b) Verification

One template

N templates user's identity or

"user unidentified"

Feature

extractor

Feature

matcher

Biometric

sensor

User interface

Feature

extractor

Feature

matcher

true/false

Figure 3.9 A Generic Biometric System. Enrollment creates an association between a user and the user's biometric characteristics. Depending on the application, user authentication either involves verifying that a claimed user is the actual user or identifying an unknown user.

Biometric

database

Biometric

database

Biometric

sensor

Biometric

database

Name (PIN)

User interface

(a) Enrollment

Feature

extractor

Biometric

sensor

Name (PIN)

User interface

(b) Verification

One template

N templates

user's identity or

"user unidentified"

Feature

extractor

Feature

matcher

Biometric

sensor

User interface

Feature

extractor

Feature

matcher

true/false

Figure 3.9 A Generic Biometric System. Enrollment creates

an association between a user and the user's biometric

characteristics. Depending on the application, user

authentication either involves verifying that a claimed user is

the actual user or identifying an unknown user .

Biometric

database

Biometric

database

decision threshold (t)

imposter profile

profile of genuine user

false match

possible

false nonmatch possible

Matching score (s)average matching value of imposter

average matching value of genuine user

Probability density function

Figure 3.10 Profiles of a Biometric Characteristic of an Imposter and an Authorized Users In this depiction, the comparison between presented feature and a reference feature is reduced to a single numeric value. If the input value (s) is greater than a preassigned threshold (t), a match is declared.

decision

threshold (t)

imposter

profile

profile of

genuine user

false

match

possible

false

nonmatch

possible

Matching scor e (s)

average matching

value of imposter

average matching

value of genuine user

Probability

density function

Figure 3.10 Profiles of a Biometric Characteristic of an Imposter and an Authorized

Users In this depiction, the comparison between presented feature and a reference

feature is reduced to a single numeric value. If the input value ( s) is greater than a

preassigned threshold ( t), a match is declared.

Figure 3.11 Idealized Biometric Measurement

Operating Characteristic Curves (log-log scale)

in crea

se th resh

o ld

in crea

sed

secu rity,

d ecrea

sed

co n v en

ien ce

d e c re

a se

th re

sh o ld

d e c re

a se

se c u r ity

in c e a se

c o n v e n ie

n c e

0.0001% 0.001% 0.01% 0.1%

100%

10%

0.1% 1% 10% 100%

false match rate

f a ls

e n

o n

m a t c h

r a t e

e q u a l e r r o r r

a te

l in

Figure 3.11 Idealized Biometric Measurement

Operating Characteristic Curves (log-log scale)

0.0001%0.001%0.01%0.1%

100%

10%

0.1%

1%10%100%

false match rate

Face Fingerprint

0.0001% 0.1%

10%

100%

0.001% 0.01% 0.1% 1% 10% 100%

Voice Hand Iris

false match rate

fa ls

e no

nm at

ch r

at e

Figure 3.12 Actual Biometric Measurement Operating Characteristic Curves, reported in [MANS01]. To clarify differences among systems, a log-log scale is used.

Face Fingerprint

0.0001%

0.1%

10%

100%

0.001% 0.01% 0.1% 1% 10% 100%

Voice Hand Iris

false match rate

Figure 3.12 Actual Biometric Measurement Operating Characteristic Curves, reported

in [MANS01]. To clarify differences among systems, a log-log scale is used.

Figure 3.13 Basic Challenge-Response Protocols for Remote User Authentication

U Host

Client

U, User

E(r’, BS’(x’))

E–1E(r’, BS’(x’)) = (r’, BS’(x’)) extract B’

from (r’, BS’(x’)) if r’ = r AND x’ = x

AND B’ = B(U) then yes else no yes/no

(d) Protocol for dynamic biometric

if f(r’, h(W’)) = f(r, h(W(U)))

then yes else no yes/no

(b) Protocol for a token

r, random number x, random sequence

challenge E(), function

(r, x, E())

f(r’, h(W’))

(r, h(), f())

B’, x’ BS’(x’) r’, return of r

P’ W’ password to

passcode via token r’, return of r

U Host

Client

U, User

E(r’, D’, BT’)

E–1E(r’, P’, BT’) = (r’, P’, BT’)

if r’ = r AND D’ = D AND BT’ = BT(U)

then yes else no yes/no

r, random number E(), function(r, E())

B’ BT’ biometric D‘ biometric device

r’, return of r

U Host

Client

U, User r, random number h(), f(), functions

if f(r’, h(P’)) = f(r, h(P(U)))

then yes else no yes/no

(b) Protocol for a password

f(r’, h(P’))

(r, h(), f())

P’ r’, return of r

U Host

Client

U, User r, random number h(), f(), functions

Figure 3.13 Basic Challenge-Response Pr otocols for Remote User Authentication

Host

Client

U, User

E(r’, BS’(x’))

–1

E(r’, BS’(x’)) =

(r’, BS’(x’))

extract B’

from (r’, BS’(x’))

if r’ = r AND x’ = x

AND B’ = B(U)

then yes else no

yes/no

(d) Protocol for dynamic biometric

if f(r’, h(W’)) =

f(r, h(W(U)))

then yes else no

yes/no

(b) Protocol for a token

r, random number

x, random sequence

challenge

E(), function

(r, x, E())

f(r’, h(W’))

(r, h(), f())

B’, x’ BS’(x’)

r’, return of r

P’ W’

password to

passcode via token

r’, return of r

Host

Client

U, User

E(r’, D’, BT’)

–1

E(r’, P’, BT’) =

(r’, P’, BT’)

if r’ = r AND D’ = D

AND BT’ = BT(U)

then yes else no

yes/no

r, random number

E(), function

(r, E())

B’ BT’ biometric

D‘ biometric device

r’, return of r

Host

Client

U, User

r, random number

h(), f(), functions

if f(r’, h(P’)) =

f(r, h(P(U)))

then yes else no

yes/no

(b) Protocol for a password

f(r’, h(P’))

(r, h(), f())

P’

r’, return of r

Host

Client

U, User

r, random number

h(), f(), functions

Attacks Authenticators Examples Typical defenses

Client attack

Password Guessing, exhaustive search

Large entropy; limited attempts

Token Exhaustive search Large entropy; limited attempts, theft of object

requires presence Biometric False match Large entropy; limited

attempts

Host attack

Password Plaintext theft, dictionary/exhaustive

Hashing; large entropy; protection of password

database Token Passcode theft Same as password; 1-time

passcode

Biometric Template theft Capture device authentication; challenge

response

Eavesdropping, theft, and copying

Password "Shoulder surfing" User diligence to keep secret; administrator

diligence to quickly revoke compromised passwords; multifactor authentication

Token Theft, counterfeiting hardware

Multifactor authentication; tamper resistant/evident

token

Biometric Copying (spoofing) biometric

Copy detection at capture device and capture device

authentication

Replay

Password Replay stolen password response

Challenge-response protocol

Token Replay stolen passcode response

Challenge-response protocol; 1-time passcode

Biometric Replay stolen biometric template response

Copy detection at capture device and capture device

authentication via challenge-response protocol

Trojan horse Password, token,

biometric Installation of rogue

client or capture device Authentication of client or

capture device within trusted security perimeter

Attacks Authenticators Examples Typical defenses

Client attack

Password Guessing, exhaustive

Large entropy; limited

attempts

Token Exhaustive search Large entropy; limited

attempts, theft of object

requires presence

Biometric False match Large entropy; limited

attempts

Host attack

Password Plaintext theft,

dictionary/exhaustive

Hashing; large entropy;

protection of password

database

Token Passcode theft Same as password; 1-time

passcode

Biometric Template theft Capture device

authentication; challenge

response

Eavesdropping,

theft, and

copying

Password "Shoulder surfing" User diligence to keep

secret; administrator

diligence to quickly revoke

compromised passwords;

multifactor authentication

Token Theft, counterfeiting

hardware

Multifactor authentication;

tamper resistant/evident

token

Biometric Copying (spoofing)

biometric

Copy detection at capture

device and capture device

authentication

Replay

Password Replay stolen password

response

Challenge-response

protocol

Token Replay stolen passcode

response

Challenge-response

protocol; 1-time passcode

Biometric Replay stolen biometric

template response

Copy detection at capture

device and capture device

authentication via

challenge-response protocol

Trojan horse

Password, token,

biometric

Installation of rogue

client or capture device

Authentication of client or

capture device within

trusted security perimeter

Denial of service

Password, token, biometric

Lockout by multiple failed authentications

Multifactor with token

Denial of

service

Password, token,

biometric

Lockout by multiple

failed authentications

Multifactor with token

Figure 3.14 General Iris Scan Site Architecture for UAE System

Iris workstation

Iris Engine 1 Iris Engine 2

Iris Merge Remote

Iris scanner

Iris workstation

LAN switch

Network switch

Iris scanner

Iris workstation

Iris scanner

Iris database

Figure 3.14 General Iris Scan Site Architecture for UAE System

Iris workstation

Iris Engine 1 Iris Engine 2

Iris Merge

Remote

Iris

scanner

Iris workstation

LAN switch

Network

switch

Iris

scanner

Iris workstation

Iris

scanner

Iris

database

Internet

Issuer (e.g., bank)

Issuer-owned ATM

(a) Point-to-point connection to processor

(b) Shared connection to processor

Processor (e.g., Fidelity)

EFT exchange e.g., Star, VISA

Processor (e.g., Fidelity)

EFT exchange e.g., Star, VISA

Issuer's internal network

Figure 3.15 ATM Architectures. Most small to mid-sized issuers of debit cards contract processors to provide core data processing and electronic funds transfer (EFT) services. The bank's ATM machine may link directly to the processor or to the bank.

Internet

Issuer

(e.g., bank)

Issuer

(e.g., bank)

Issuer-owned ATM

(a) Point-to-point connection to pr ocessor

(b) Shared connection to pr ocessor

Processor

(e.g., Fidelity)

EFT exchange

e.g., Star, VISA

Processor

(e.g., Fidelity)

EFT exchange

e.g., Star, VISA

Issuer's

internal network

Figure 3.15 ATM Architectures. Most small to mid-sized issuers of debit

cards contract processors to provide core data processing and electronic

funds transfer (EFT) services. The bank's ATM machine may link

directly to the processor or to the bank.