Identity Management

We will focus on identity management. Manual user registration provides for the
greatest granularity, but it is generally regarded as having too high of an administrative
burden to be effective. Today, it is often replaced with an automated provisioning
solution for identity management. It provides a framework for managing access control
policies by role, interconnection with IT systems, and workflows to guide sign off
delegated administration, password management, and auditing. The identity
management life cycle includes provisioning, proofing, authorization, maintenance,
and entitlement. We will introduce all five areas in detail. Now, let us take a closer look
at the first area in the identity management life cycle, provisioning.

Provisioning:
This is the process of creating or setting up all procedures and tools to manage the life
cycle of an identity. Provisioning includes creation of the identifier for the identity,
linkage to the authentication providers, setting and changing attributes and privileges,
and decommissioning of the identity. As we look at identity provisioning, keep in mind
that while most of these processes are designed around human users, organizations are
finding that they need to work equally well, if not better, for non-human users and
entities. Hardware or software robots, IoT devices, autonomous mobile systems, and
even endpoint devices are more and more being considered as identities to manage,
rather than just as devices with addresses or executable files with process IDs. We'll
highlight issues and aspects for the non-human as they come up. Three different forms
of identity provisioning are now in common use with each providing complementary
capabilities for the organization.

Manual identity provisioning is performed for human users by human

administrators, starting with hiring managers, human resource administrators, and other
staff members and many organizations. It starts with an initial request to create a system
identity, usually by a hiring or other action, and requires initial decisions regarding
position or roles, types of data or systems for which access is needed, and the range of
capabilities or privileges the new identity will need. Those with oversight over this new
person and their identity are also identified at this point. The rest of the provisioning
process, including proofing, issuance of tokens, user IDs, etc., is done as part of
provisioning. Updates to deployed access control system's databases are often done in
an overnight batch update process. For large, geographically dispersed or
organizationally complex enterprises, this process can take two days to push the new
identity to all systems.

Self-provisioning of identity allows the end user to initiate, perform, or requests

changes in various parameters related to their identity and privileges as known to the
organizations IAAA systems. Many systems permit and actively encourage users to
reset their passwords, challenge questions and answers, or other what you know
security factor items without requiring a human administrator or security involvement.
Changes to personal addresses, phone numbers, family or dependence information and
other related data may also be self-initiated, but may require administrators to accept
proofs of the changes. Self-provisioning can also play a role in privilege escalation.
When a user attempts to access a system asset they currently do not have privileges for,
they may be able to click on a Contact Your Administrator or request access link. This
may invoke either an automated challenge mechanism or a notification to a human
owner or administrator for review. Just.-in-time provisioning allow someone to create
a whole new identity on a system, accept a specific set of privileges, and begin using it
right away. Joining a blog community or signing up to edit a Wikipedia page are
commonplace examples of just-in-time provisioning. Different identity assurance
levels may be achieved by organizations based on their needs and their risk postures.
At the lowest level, IAL1, no effort is expended to validate that the information claimed
by the entity asking for an identity on the system is in fact who or what they claim to
be. IAL2 requires identity proofing using an online identity authentication service,
which can be done with services like social media systems. IAL3, however, requires
physical verification of documents that prove the identity claim, such as government
issued identity cards, passports, birth certificates, marriage certificates, or otherwise
authenticated. The second area included in the identity management life cycle is identity
Proofing:
It verifies people's identities before the enterprise issues them accounts and credentials.
It is often based on life history, such as credit report or biometrics, such as a fingerprint
or a facial scan. Identity can also be verified by manually examining an individual's
passport, driver's license, or other official document.
But verifying people's identities is only the

First step. According to NIST Special Publication 800-63A, there are three
steps in the identity proofing process.

First, Resolution.
Distinguishing a person's identity in the context of the system.

Second, Validation.
Collecting, identifying information from the user, such as username, password, answers
to security questions, and confirming the accuracy of that information. In this step,
validation may require the user to answer one or more pre-established security
questions, along with an account number, billing, postal code, or other information the
user is expected to know.

Third Verification:
Verifying the user is who they claim to be. The identity proofing service provider
verifies whether the documentation and answers provided align with a real person.
Identification
This is the process of establishing a unique way to identify or distinguish one user or
process from another. FIPS 201-1 defines identification as the process of discovering
the true identity. For example, origin and initial history of a person or item form the
entire collection of similar persons or items. The importance of identification is to
establish accountability so that the actions of a person can be associated with the
individual who committed those actions. This is important for reasons of non-
repudiation and investigation. Identification may be done in many ways, including user
IDs, Social Security numbers, account numbers, email addresses, biometrics, and DNA.
These are often good identifiers because they are more likely to be unique than a
person's name. A challenge faced by many organizations to allow people to register
their own accounts and set their own identities. This removes the overhead of
administrators trying to manage identities on behalf of the users, but also presents the
opportunity for misuse. As a result, utilities such as completely automated Public
Turing test to tell computers and humans apart are increasingly used to try to ensure
that identities are only granted to real people and not some type of bot that is attempting
to create multiple IDs on the system. The process of establishing identities on a system
should be a secure process so that the only legitimate users are able to obtain a user ID.
Another form of identification is using a location or device to establish an identity. This
is often called node authentication. It uses MAC, media access control address, IP
address, CPU serial number, or other device authentication techniques to identify the
location on administrator or user is using to login from. Many wireless devices use
MAC filtering to restrict users to only being able to login from registered wireless
devices. For mobile devices, the IMEI number may be part of this node identification
data.
Once users have stated their identity, we need to validate that they are the rightful
owners of that identity.

Authentication:
This process of verifying or proving the ID is known as authentication. There are three
common methods of authentication.
The first one is something you know, for example, passwords or paraphrases. The
second one is something you have such as tokens, memory cards or smartcards. The
third one is something you are, like bio-metric or measurable characteristics.
Knowledge-based authentication has been in use for thousands of years. Ensuring that
someone is authentic and asking them for a passphrase or secret code has been used to
differentiate between authorized and unauthorized personnel. Today we use
knowledge-based authentication by using a personal identification number, pin,
password, passphrase, or some other secret value that only authorized personnel should
know. The problem with this type of authentication is often vulnerable to shoulder
surfing or sniffing. An unauthorized person discovers valuable information by looking
over a user's shoulder or sniffing the communication during the login process. This data
can also be prone to social engineering based estimation, since attackers can exploit
information on social media or other sources to guess what a user might find memorable
and useful as an identity token. Since passwords and other knowledge-based systems
often use the same password for a period of time, perhaps 30 days. Thus, the password
capture would allow an attacker to perform a replay attack under the guise of the
authorized user. Knowledge-based passwords are also subject to attacks such as brute
force, dictionary and rainbow tables, which will be explained later in the course when
we have examined hash values. A common problem with knowledge-based systems is
a forgotten password. Within the organization, a password may be reset by the help
desk, but the challenge is always how to ensure that the passwords are only reset for
the correct user and not someone else calling in pretending to be another user and
having that person's password reset. This gets even more complicated. Think like this.
When the caller is claiming to have somehow lost sight of all of the, what you know,
security tokens and is asking for a complete reset of every parameter related to their
account. For many years, knowledge-based authentication in terms of passwords, was
the most common methodology in access control systems. However, today, weaknesses
and the implementation of encryption for passwords have effectively rendered these
knowledge-based methodologies obsolete.
In October 2005, the Federal Financial Institutions Examination Council provided a
recommendation to US banks, that included a requirement to replace passwords and
single factor authentication with multi-factor authentication. The recommendation
clearly pointed out that passwords alone are simply no longer a secure method for
authenticating users in the internet environment. The best practice and access control is
to implement at least two of the three common techniques for authentication in your
access control system, such as knowledge-based, token-based, or characteristic-based.
A fourth, access control factor starting to see widespread application might be called
where you are right now, as it considers the user's physical location and network
location to see if they are consistent with established norms for that identity. For
example, a military member traveling to an at-risk area might attempt to access
unclassified but sensitive systems from a temporary work or lodging location with their
smart phone or laptop providing IP address and geo-location data. If such access is
permitted from such a location at this particular time, for that particular person, the
access can be allowed to proceed. Using this fourth factor may be a step on the way to
implementing a more fully capable UEBA based access control solution. Another
authentication factor is based on ownership or physical possession. This has been in use
for many decades. A person's identity could be authenticated through a letter of
attestation, passport, driver's license, or badge, with a presumption that the issuer of
that physical document or token had sufficient recognition, authority or credibility to
be attesting to someone's identity using token. Today, we also see ownership through
the use of hardware-based and software-based tokens, smartcards, key fobs, and other
hardware or software mechanisms. We have covered knowledge-based authentication,
multi-factor authentication, and ownership. Let's shift the conversation to tokens and
various types of tokens

Types of Tokens
Asynchronous Token
An asynchronous token, such as the event-driven, asynchronous token from Secure
Computing called the SafeWord, is eToken PASS that provides a new one-time
password with each use of the token. It can be configured to expire on a specific date,
but its lifetime depends on its frequency of use.
The token can last between five and 10 years and effectively extend the time period
typically used in calculating the total cost of ownership in a multi-factor authentication
deployment. In the use of an asynchronous one-time password token, the access control
subject typically executes a five-step process to authenticate identity and have access
granted:
The authentication server presents a challenge request to the access control subject.
The access control subject enters the challenge into the token device.
The token device mathematically calculates a correct response to the authentication
server challenge.
The access control subject enters the response to the challenge along with a password
or PIN.
The response and password or PIN is verified by the authentication server and if correct,
access is granted.
The use of a PIN, together with the value provided from the token, helps to mitigate the
risk of a stolen or lost token being used by an unauthorized person to gain access.

Time Based
Time-based authentication systems using synchronous tokens use time-based one-time
passwords (TOTP) to allow for an additional authentication factor to be
generated during the overall login authentication process by software on a user’s
endpoint device. A variety of implementations are possible for this, such as having the
user endpoint scan a QRC code displayed by the host and using that QRC as an input
to a TOTP generator.
In 2011, the Internet Engineering Task Force issued (via RFC 6238) a standard
definition of a time-based one-time password, which uses the hash functions associated
with hashed message authentication codes (HMAC); we will discuss this more
in chapter 3, module 3. These systems rely on both host and endpoint to be able to
synchronize their internal clocks to within a small interval of each other (such as 30
seconds), from which both the authenticator and the authenticatee (as the host and
endpoint are known in this instance) compute the TOTP. If an attacker has copied a
large enough authentication database, they may be able to calculate new, valid TOTP
values whenever they want to, so there are some vulnerabilities associated with this
approach. But if that time interval is short enough, it effectively is forcing the attacker
to spoof credentials, phish out the TOTP values, so this risk is manageable.
In practice, TOTPs are not valid for more than 30 seconds as a result.

Event Based
Event-based authentication uses a physical event, such as the push of a button on a
security token device, to generate the sequence number that is the seed value needed for
the one-time password generator algorithm. Clearly, this requires the host to be
initialized to the same starting sequence number as the token is initialized, and to keep
track of each token’s current (or last-used) sequence number value. That starting value
should be kept secret, as should the current value in the token device and in the host’s
records (in the authentication database, presumably). A financial institution which
might issue tens of thousands of token devices to their customers would need to store
the token device identifiers (MAC addresses or similar), their initialization value, and
their current value, with each customer’s account associated with that token.
In many implementations, this uses the same HMAC one-time password approach that
TOTP uses; in fact, it’s considered by some security professionals to be
the original one-time password, but as we’ll see in chapter 5, this is not quite correct.

Smart Cards
Smart card tokens contain memory, one or more processing units, interfaces, and a
tamper-resistant security system. They are designed to be managed by a central
administration system, and require a card reader device, such as the typical card reader
on an ATM or fuel pump at a gasoline station. Smart cards come in a variety of form
factors and packaging, such as the chips on credit cards, SIM chips used in mobile
phones, and other forms. Reader devices can be contactless or contact type:
A contact card reader requires physical contact with the card reader. There are two
primary types of contact for these readers:
Contactless card readers are quickly gaining in popularity and typically rely on radio-
frequency identification (RFID) technology to facilitate reading. The additional
security mechanisms found in contactless card applications can include
challenge/response-based encryption safeguards to reduce the risk of “card skimming”
whereby the account information is stolen in an otherwise legitimate transaction.

Memory Cards
The significant difference between a memory card and a smart card is that the memory
card does not have any onboard processing capability, whereas the smart card of course
does. Memory cards often do not contain features to prevent or limit
tampering. Memory cards can be used as identity or authentication tokens so long as the
system’s security requirements do not dictate the need for a smart card to be used
instead. In most applications they have been supplanted by smart card designs.

Bluetooth and Mobile Device Tokens

Bluetooth tokens are often combined with a USB token, thus working in both a
connected and a disconnected state. Bluetooth authentication works when closer than
32 feet (10 meters). If the Bluetooth is not available, the token must be inserted into a
USB input device to function. A mobile device such as a smartphone or tablet computer
can also be used as an authentication device, providing secure two-factor identification.
Radio-Frequency Identification (RFID)
Radio-frequency identification (RFID) is the wireless non-contact use of radio-
frequency electromagnetic fields to transfer data for the purposes of automatically
identifying and tracking tags attached to objects. The tags contain electronically stored
information. Some tags are powered and read at short ranges, typically a few meters,
via magnetic fields.
Others use a local power source such as a battery or else have no battery but collect
energy from the interrogating EM field, and then act as a passive transponder to emit
microwaves or UHF radio waves. Battery-powered tags may operate at hundreds of
meters. Unlike a bar code, the tag does not necessarily need to be within line of sight of
the reader and may be embedded in the tracked object.
Some common problems with RFID are reader collision and tag collision.
Reader collision occurs when the signals from two or more readers overlap. The tag is
unable to respond to simultaneous queries. Systems must be carefully set up to avoid
this problem; many systems use an anti-collision protocol (also called a singulation
protocol). Anti-collision protocols enable the tags to take turns in transmitting to a
reader.
Tag collision occurs when many tags are present in a small area; but since the read time
is very fast, it is easier for vendors to develop systems that ensure that tags respond one
at a time. Since the tags can be read without being swiped or obviously scanned (as is
the case with magnetic strips or barcodes), anyone with an RFID tag reader can read
the tags embedded in clothes and other consumer products without knowledge. For
example, customers could be scanned before entering a store to see what they are
carrying. A customer might then be approached by a clerk who knows what is in the
customer’s backpack or purse, and the clerk can suggest accessories or other items. For
various reasons, RFID reader/tag systems are designed so that distance between the tag
and the reader is kept to a minimum. However, a high-gain antenna can be used to read
the tags from much farther away, leading to privacy problems.
One of the main concerns with RFID tags is that their contents can be read by anyone
with an appropriately equipped scanner — even after it has been taken out of the store.
One technology that has been suggested is a zombie RFID tag, a tag that can be
temporarily deactivated when it leaves the store. The process would work like this: A
customer brings a purchase up to the register, the RFID scanner reads the item, the
customer pays for it, and as the customer leaves the store, a special device sends a signal
to the RFID tag to “die.” That is, it is no longer readable. The “zombie” element arises
if a customer brings an item back to the store. A special device especially made for that
kind of tag “re-animates” the RFID tag, allowing the item to re-enter the supply chain.
One variation on this is to use hash chains (the repeated use of a hashing function) to
generate a complex ongoing series of one-time passwords starting from a secret shared
key. Given that each password is unique, it is very unlikely that an unauthorized user
would be unable to determine what the password expected by the authentication server
would be, even if the attacker had access to a previous password. Again, if the attacker
can get hold of the shared secret and can know how many times the hash chain has been
used, they could conceivably predict the next one-time password value.

Disconnected Tokens
Disconnected tokens require no connection either logical or physical. When using time-
synchronization, the synchronization is done before the token is distributed to the client.
As discussed earlier, these devices display a value (the password) which is entered via
the login.

Connected Tokens
Connected tokens are physically connected to the computer with which the user is being
authenticated.
With these types of tokens, the time synchronization occurs when the token is inserted
into an input device. The token automatically transmits the authentication information
when a connection is made.
These types of devices do require an input device to be installed, either built-in (to the
keyboard, etc.) or plugged in via a port USB or FireWire (IEEE 394).

Contactless Tokens
Using an in-built antenna RFID and NFC devices enable the use of contactless tokens to
have connectivity to transmit login credentials or payment information. While this may
be more convenient for the user than the devices previously mentioned, they do present
the additional problem of snooping or cloning.