Class Notes UNIT III - BCS-404 B Essentials of Computer Security
Class Notes UNIT III - BCS-404 B Essentials of Computer Security
For example, user Alice Toklas could have the user identifier ABTOKLAS. This information
needs to be stored on any server or computer system that Alice wishes to use and could be
known to system administrators and other users. A typical item of authentication information
associated with this user ID is a password, which is kept secret (known only to Alice and to
the system)'. If no one is able to obtain or guess Alice’s password, then the combination of
Alice’s user ID and password enables administrators to set up Alice’s access permissions and
audit her activity. Because Alice’s ID is not secret, system users can send her e-mail, but because
her password is secret, no one can pretend to be Alice.
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 that user authentication is distinct from
message authentication. 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.
Typically the password is stored in hashed form on the server and this Hash code may not be
secret.
This chapter first provides an overview of different means of user authentication and then examines
each in some detail.
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 (gives guarantee) 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.
Means of Authentication
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.
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 lD, 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 lD 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 lD is used in what is referred to as discretionary (Optional) access control. For
example, by listing the lDs of the other users, a user may grant permission to them to
read files owned by that user.
The Vulnerability of Passwords
In this subsection, we outline the main forms of attack against password-based authentication
and briefly outline a countermeasure strategy.
Typically, a system that uses password-based authentication maintains a password file
indexed by user ID. One technique that is typically used is to store not the user’s password but
a one-way hash function of the password.
We can identify the following attack strategies and countermeasures:
• 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 lDs. 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 (avoid) 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
inactivily. 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
RULE E N FORCEMENT: The first approach is a simple system for rule enforcement. For
example, the following rules could be enforced:
• All passwords must be at least eight characters long.
• In the first eight characters, the passwords must include at least one each of
uppercase, lowercase, numeric digits, and punctuation marks.
These rules could be coupled with advice to the user. 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, which enforces a variety of rules on passwords and is configurable by the
system administrator.
PASSWORD CHECKER: 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.