Rutgers Authentication Analysis and Strategy
Introduction
Due to the highly distributed Rutgers computing environment, much of the responsibility
for the application of the appropriate level of information security controls resides with
department management. The University has an expectation that all unit computing staff
will exhibit "due care" in the administration of computing systems. However, in order to
deliver a consistent and scalable security model to the University and to ensure that it is
meeting any regulatory obligations, it is essential to provide guidance in the form of
policies, standards, and guidelines.
Authentication is a key component of effective security architecture at the University.
The application of authentication standards and guidelines demonstrate in a methodical
way that a department or business unit conforms to industry best practices, and in many
cases demonstrates regulatory compliance. The purpose of this paper is develop a
framework for which a cost effective set of authentication procedures to be identified to
university, so that a consistent authentication model can be applied by both central and
distributed units. The following Rutgers units participated in the analysis and resultant
framework.
Charles Hedrick, Office of Information Technology (OIT), Chief Technology
Officer
Mike Gergel, OIT – Director of Information Protection and Security
David Badger, OIT – Associate Director, OIT - Enterprise Application Services
Timothy Hayes, OIT – Information Protection and Security
Douglas McCrea, IT Director, Office Of Undergrad Educ. & Student Affairs
Tom Vosseler, IT Director, SAS
Nicholas Di Giovanni, Information Systems Audit Manager
While this paper focuses on authentication, it is recognized that this aspect of security
does not exist in a vacuum. Other factors can lead to evasion of even the most robust
authentication scheme. In particular, the human element is often a “weak link” through
lack of awareness or non-compliance with policies, procedures, and best practices.
Consequently, assuring reliable authentication depends on each unit having in place a
sound overall security program of administrative, technical, and physical safeguards.
Authentication Standard
Authentication refers to the process where a person or system identity is verified based
upon a credential. In most cases the credential offered is a userid and password, while
other methods exist where a greater level of confidence is required. Since the verification
of these credentials is the primary access to systems, it becomes a critical part of
organizations security architecture.
Authentication can involve something the user knows (i.e. password), commonly referred
to as single factor authentication. A higher degree of confidence can occur with two
factor authentication, where something the user has (smart card) is combined with
something a user knows. A third factor in authentication can be something the user “is”
(fingerprint or voice pattern). Using additional factors reduces the likelihood that a
system will be compromised and makes it more difficult for someone to gain
unauthorized access to a system. However, as the number of factors required increase, a
corresponding increase in costs also occurs.
Implementing cost effective authentication controls requires an organization to assess the
sensitivity of the data it is protecting. It is not economically feasible to apply costly
technical solutions to data assets whose value to the university is less than the
consequences that would be occur if the information were to be compromised.
The Office of Management and Budget (OMB 04-04) defines four levels of
authentication assurance for electronic transactions in terms of the likely consequences of
an authentication error. These levels are determined by the degree of confidence needed
in the process used to establish identity and in the proper use of the established
credentials.
Level 1 — Little or no confidence in the asserted identity' validity;
Level 2 — Some confidence in the asserted identity' validity;
Level 3 — High confidence in the asserted identity' validity; and
Level 4 — Very high confidence in the asserted identity' validity.
In order to provide guidance on the technical requirements supportive of each level, the
National Institute of Standards and Technology (NIST) published the summary
document, NIST 800-63, “Electronic Authentication Guideline”.
LEVEL 1
At Level 1, there is little or no confidence that exists in the asserted identity; it is
usually self-asserted; and is essentially a persistent identifier. There are typically
no identity proofing is required at Level 1. For example, authentication at this
level may be appropriate for self-registration websites.
LEVEL 2
Successful authentication at Level 2 requires that the claimant prove, through a
secure authentication protocol that he or she controls a single authentication
factor. Approved cryptography is required to prevent eavesdroppers. At Level 2,
identity proofing requirements are introduced, requiring presentation of
identifying materials or information. The password associated with the Rutgers
NetId is an example of a Level 2 authentication credential.
LEVEL 3
Successful authentication at Level 3 requires that the claimant prove
that he or she controls a minimum of two authentication factors.
Eavesdropper, replay, on-line guessing, verifier impersonation and
man-in-the-middle attacks are prevented. At Level 3, there is high
confidence in the asserted identity's accuracy. There is a strong
identity proofing requirement at this Level. Strong cryptographic
techniques are used to protect all operations. An implementation of one
time password system such as a Safeword Card (a token requiring a PIN),
biometrics coupled with a password/PIN, and public key technologies (key
and passphrase) are potentially appropriate for this Level.
LEVEL 4
Level 4 is intended to provide the highest practical remote network
authentication assurance. Level 4 is similar to Level 3 except that only
“hard” cryptographic tokens are allowed. By requiring a physical token
which cannot readily be copied and requiring operator authentication at
Level 2 and higher, this level ensures good, two-factor remote
authentication. Eavesdropper, replay, on-line guessing, verifier
impersonation and man-in-the-middle attacks are prevented. Strong,
approved cryptographic techniques are used for all operations. Based on
the scope of the data types at Rutgers, Level 4 authentication is not
required. Acceptable mechanisms include cryptographic smart cards.
At Rutgers, there are data types, which we broadly attempt to classify into three
categories, “Restricted”, “Limited Access”, and “Public”. Based on how a data asset is
classified, commensurate controls should be implemented to ensure its confidentiality,
integrity, and availability. For instance, the following chart presents a representation on
how the mapping would be conceptually applied.
Level
Data
Classification
1
Public
2
Limited
Access
Type of Access
Examples
Level 1 is for
unauthenticated access.
There is no knowledge of
the user’s identity.
Public web sites e.g.
www.rutgers.edu; selfregistration sites
Level 1 is also appropriate
for users who are loosely
affiliated with the University
The set of users loosely affiliated
with the University may include
Guests; Group accounts
Level 2 is appropriate for
users accessing information
This includes users of the
MyRutgers portal and other
they created, are the subject
of or is intended for them; or
because of their work
responsibilities have access
to information that is not
their own.
portal-like self-service functions.
This includes activities such as:
reading/writing email, checking
calendar, RIAS, enrolling,
SAKAI, etc.
This includes users who have:





3
Restricted
Level 3 is appropriate for
users who because of their
work responsibilities have
access to restricted
information that is not their
own. This authority presents
a higher risk and thus a
higher level of confidence in
the user’s identity.
Access to other people’s
information (e.g. registrar
staff that can accept tuition
payments, but does not
have access to data
classified as "restricted";
or an instructor that can
enter grades for their
students).
Access to
programs/files/data on an
INTERNAL system (e.g.
developers and DBA’s)
Access to an INTERNAL
system as root or admin
(e.g. SysAdmin)
Access to an internal
system that IS NOT
subject to regulatory
requirements (e.g. GLBA,
HIPAA, PCI etc)
Authentication at this level
required for InCommon
Bronze designation.
This includes users who have:

Access to more than one’s
own personal or
RESTRICTED
information (e.g. an HR
person who can
view/update records for all
personnel in their
workgroup (aka functional
users).




Access to
programs/files/data on a
RESTRICTED system
(e.g. developers and
DBA's)
Access to a
RESTRICTED system as
root or admin (e.g.
SysAdmin)
Access to a restricted
system that IS subject to
regulatory requirements
(e.g. HIPAA, PCI etc)
Authentication at this level
required for InCommon
Silver designation.
Password Risks
There are numerous vectors of attack which may lead to password compromise. When
considering the appropriate blend of authentication alternatives, these threats and the
corresponding consequences should be addressed.
Password Capturing
Password Capturing is an attacker acquiring a password from storage, transmission, or
user knowledge and behavior.
Regarding password storage, there are cases where account and password credentials are
stored on hosts for operating system and application authentication purposes. If not stored
properly, this presents an opportunity for attackers with physical or logical access to gain
access.
There are cases where passwords or their hashes are transmitted over the network for
authentication purposes. In cases where an encrypted protocol such as SSL is NOT
used, they are subject to threats such as “sniffing”. Replay attacks, where an attacker
records the data of a successful authentication and replays this information to attempt to
falsely authenticate to the verifier are also possible.
Passwords may be captured by taking advantage of user knowledge and behavior by both
technical and non-technical means. Through observation or other means such as shoulder
surfing, an attacker can gain access to a user’s password. Social engineering attacks,
including “phishing” attempts, are aimed at obtaining authentication credentials by
tricking a user into using an insecure authentication protocol, or into loading malicious
code onto their computer.
There are also many technical attacks that target the user’s computing environment. They
vary in their sophistication from simple key loggers to advanced Trojan programs that
can gain control of the customer’s computer. Through keystroke loggers, attackers can
capture keystrokes of a customer with the intention of obtaining any password typed in
by the customer or other manually entered authentication key data. This class of malware
monitors the keyboard for activity, and provides the observation to the attacker. Trojan
horses and other forms of malware can also monitor user activity to gather usernames,
passwords, and other sensitive pieces of information for attackers.
The threats in this category are mostly mitigated through securing the user’s hosts
effectively, including effective patch management, spyware, and anti-virus controls.
Effective security awareness is also necessary to provide the user information necessary
to protect their credentials, and to avoid malware infections and recognize social
engineering attacks.
Password Guessing and Cracking
Brute force, common password and dictionary attacks, which aim to determine a
password. The attacker may try to guess a specific customer’s password, try a few
commonly used passwords against all customers, or use a pre-composed list of passwords
to match against the password file (if they can recover it), in their attempt to discover a
legitimate password.
Password Attack Mitigation
Implementing technical authentication standards based up the sensitivity of data and
corresponding consequences of loss provides efficiency in authentication. In the cases
where a high confidence is required to accessing restricted data, consideration should be
given to provision a stronger authentication mechanism. Passwords do not provide an
adequate degree of safety for systems that process or store data elements defined as
restricted.
There are many cases where strong authentication is not cost effective such as when
“limited access” data is involved. In these cases, there are additional management
decisions that can effectively strengthen the authorization and authentication to Rutgers
systems at this level. These considerations must be analyzed with respect to their broad
based impact to applications and the user environment. In many cases, applications or
systems may not have the inherit capability to adopt certain policy criteria. In some cases,
applications can be updated to implement enhanced control criteria, but these must be
reviewed on a case by case basis. The techniques most frequently used to improve the
security of passwords include the following:
1. Password Expiration - Password expiration is the “aging” of passwords, where a
user is forced to change their password after a pre-determined period of time.
Many enterprises adopt password expiration policies as a standard to enhance the
protection of their systems. Traditionally, this strategy was often thought of a way
to limited the likelihood of compromise through “password guessing”, or
minimize the damage resulting from a password that has already been
compromised.
2. Password Length - Password length is a criteria applied to passwords that
establishes the minimum number of characters required when creating a
password.
3. Password Complexity - Password complexity generally involved the character
sets required to construct a password. These character sets can involve, employing
the full set of alphanumeric characters, upper and lower case, numbers, symbols,
and / or requiring the use of a combination increases the difficulty in guessing a
password.
4. Password Lockout - the locking of an account temporarily after a series of failed
login attempts are detected in a short period of time. Temporary lockouts help
thwart or slow the ability to complete a password attack.
5. Multi-factor - Authentication requires two of three forms of credentials:
something you have, something you know, and something you are. This includes
token cards, certificates, and biometrics when properly implemented with each
other or with a PIN.
Risk / Mitigation Analysis
The table below represents the “effectiveness” of applying possible authentication
mitigation strategies as they apply to the “risk”. For the purposes this analysis the
following risks are considered.
Keylogging: all classes of attack where the password, as typed by the user, can be
captured without the user's knowledge. This includes malware installed on a client
system, malicious or compromised services, or unsecured transmission of the password
over a network.
Brute force: attacks against the password with no special knowledge, the goal is to try all
possible password combinations for a single user.
Bulk guessing: attacks against a large number of users using a minimal number of
commonly selected passwords.
Phishing: all social engineering attacks which try to convince the user to hand over their
password to the attacker.
Special-access: attacks where the attacker has some form of special access to the user's
password including “shoulder surfing” and administrative access to stored passwords (or
their hashes)
Shared: attacks where the password is given to another user and then misused or further
distributed to another unauthorized party (secretaries, family members, co-workers, etc)
Risk
Mitigation
Expiration
Length
Complexity
Lockout
Multi-factor
Keylogging
None
None
None
None
High
Brute force
Low
High
Medium
High
High
Bulk guessing
None
High
Medium
Low
High
Phishing
None
None
None
None
High
Special-access
None
None
None
None
High
Shared
None
None
None
Low
Medium
Recommendations
Password Expiration - Due to the speed of current processors, a password expiration
strategy is an ineffective mitigation strategy for password guessing attacks. Since one
cannot reliably predict the time of a successful guessing attack, password expiration does
little to mitigate the damage that would result. Moreover, users that are confronted with
frequent password change intervals often resort to writing their password down, or
selecting a password by the use of patterns (i.e. month, day of week, etc). Password
changes can also have a direct impact on the productivity, as well as the usability and
associated indirect costs of such systems (e.g., increased number of calls to the help
desk).
While the consensus opinion is that the expiration of passwords does not materially
reduce the likelihood that an account will be compromised, it is acknowledged that
expiration over a period of time may help in cases of changes to policy, or where
credentials have been stolen. It is recommended that Rutgers considers a password
expiration of 1 year for these purposes.
Password Length - Increasing the password length may increase the difficulty in
password guessing attacks. Due to the benefit gained from enhancing this control, it is
recommended that the minimum length be increased to 10 characters and all system
handling passwords be upgraded to accommodate passwords of up to 60 characters.
Systems accepting passwords should be able to accept at least all printable ASCII
characters.
Password Complexity - At Rutgers, the current character set represents sufficient
complexity. Currently, the character set classes and minimum requirements are as
follows.
Minimum number of password character classes: 3
Number of old keys kept: 5
Character classes:
* Lowercase letters (a-z)
* Uppercase letters (A-Z)
* Numerals (0-9)
* Special characters (e.g. $ * )
Account Lockout - Currently, a locking control is not implemented for Rutgers systems.
This control is often established to help slow down guessing attacks. Since this control
can provide an improvement in systems resilience to guessing attacks, implementing an
account lockout feature should be considered. The recommendation is to implement
controls that permit no more than an average of one failed login attempt every 30
seconds. No specific time limit or failure count is specified; the implementation must
assure that the average rate of attempts over the controlled interval does not allow more
than one password trial every 30 seconds. An acceptable example would be to lock an
account for one minute when 4 failed attempts are seen within the preceding minute.
Multi-Factor Authentication - Passwords do not provide an adequate degree of security
for systems that process or store restricted information. Passwords, as indicated above,
are vulnerable to a wide variety of attacks. Strong authentication methods are
recommended to reduce the risk associated with these high value systems.