Assignment

eko

Chapter7AuthandAuth.pptx

Home >Computer Science homework help >Assignment

Chapter 7

Authentication and Authorization

Introduction

Authentication: Identify who is at the keyboard (and prove his identity).

Authorization: Decide what he is allowed to do.

These twin controls, authentication and authorization

Ensure that authorized users get access to the appropriate computing resources

while blocking access to unauthorized users.

Should always be done in accordance with the principle of least privilege—giving each person only the amount of access she requires to be effective in her job function, and no more.

Authentication

The process by which people prove they are who they say they are.

Composed of two parts:

Public statement of identity (usually a username)

Private response to a challenge (such as a password)

Factors

Something you know

Secret word

Number

Passphrase

Something you have

Smart card

ID tag

Code generator

Something you are

Biometric factor

Fingerprint

Retinal print

Response to the authentication challenge can be based on one or more factors:

Passwords

Identifying yourself through something only you should know

Most common form of challenge response

Single-factor authentication

Not strong authentication

Other Single-factor Authentication Methods

Tokens and smart cards

Pro: better than passwords because they must be in the physical possession of the user

Con: can be lost or stolen

Biometrics (a sensor or scanner to identify unique features of individual body parts)

Pro: better than passwords because they can’t be shared—the user must be present to log in

Con: can be spoofed

Multifactor Authentication

Two or more methods of checking identity

These methods include (listed in increasing order of strength)

Something you know (a password or PIN code)

Something you have (such as a card or token)

Something you are (a unique physical characteristic)

Two-factor Authentication

The most common form of multifactor authentication

Examples:

Numeric-generator token device with an LCD screen that displays a number (either time-based or sequential), used with a password

Smart card along used with a password

Passwords aren’t very good choices for a second factor, but they are ingrained into our technology and collective consciousness, they are built into all computer systems, and they are convenient and cheap to implement.

Token or smart card along with biometrics would be much better.

Common Password-based Authentication Systems

Local storage and comparison

Central storage and comparison

Challenge and response

Kerberos

One-time password (OTP)

Local Storage and Comparison

Early computer systems did not require passwords.

In the next evolution, passwords were stored in the database unencrypted.

Today, many off-the-shelf applications use Lightweight Directory Access Protocol (LDAP) or Active Directory.

CHAP and MS-CHAP

The server that receives the request for access issues a challenge code, and the requestor responds with an hash of the code and password.

The server then compares that hash to its own hash made from the same code and password. If they are the same, the user is authenticated.

Version 2 of MS-CHAP requires mutual authentication

The user must authenticate to the server.

The server must also prove its identity by encrypting a challenge sent by the client using the client’s password. Only a server that holds the account database in which the client has a password could do so; the client is also assured that it is talking to a valid remote access server.

Kerberos

Network authentication system based on the use of tickets.

A user enters her password.

Data about the client and an authenticator is sent to the server.

The authenticator is the result of using the password (which may be hashed or otherwise manipulated) to encrypt a timestamp (the clock time on the client computer).

This authenticator and a plaintext copy of the timestamp accompany a login request, which is sent to the Kerberos authentication server (AS).

This is known as pre-authentication: the KRB_AS_REQ message.

The Kerberos KDC

Typically, both the AS and the ticket granting service (TGS) are part of the same server, as is the key distribution center (KDC). Key Distribution Center (KDC)As in other implementations of the Kerberos protocol, the KDC is a single process that provides two services: Authentication Service (AS). This service issues Ticket Granting Tickets (TGTs) that are good for admission to the ticket-granting service in its domain

The KDC is a centralized database of user account information, including passwords.

Each Kerberos realm maintains at least one KDC (a realm being a logical collection of servers and clients, comparable to a Windows domain).

The Kerberos Authentication Process

The KDC checks the timestamp from the workstation against its own time.

The KDC uses the password to encrypt the plaintext copy of the timestamp and compare the result to the authenticator. A ticket-granting ticket (TGT) is returned to the client—the KRB_AS_REP message.

The client sends the TGT to the KDC with a request for the use of a specific resource, and it includes a fresh authenticator—the KRB_TGS_REQ message, handled by the TGS.

The KDC validates the authenticator and examines the TGT.

If all is well, the KDC issues a service ticket for the requested resource—the KRB_TGS_REP message.

Part of the ticket is encrypted using the credentials of the service (perhaps using the password for the computer account on which the service lies), and part of the ticket is encrypted with the credentials of the client.

The client can decrypt its part of the ticket and thus knows what resource it may use. The client sends the ticket to the resource computer along with a fresh authenticator.

The resource computer (the client) validates the timestamp, and then decrypts its portion of the ticket. This tells the computer which resource is requested and provides proof that the client has been authenticated.

The Kerberos Authentication Process

One-time Password Systems

Algorithm that requires the password to be different every time it is used.

Like the one-time pad used in WWII. When two people need to send encrypted messages, if they each have a copy of the one-time pad, each can use the day’s password. Even if a key is cracked or deduced, it is good only for the current message.

Time-based Keys

Hardware- or software-based authenticators based on the current time of day used as a random seed.

Authenticators are

Hardware tokens (such as a key fob, card, or pin pad)

Software

One-time authentication code changes every 60 seconds.

The user combines his personal identification number (PIN) and this code to create the password.

A central server can validate this password, since its clock is synchronized with the token and it knows the user’s PIN.

Since the authentication code changes every 60 seconds, the password will change each time it’s used.

Sequential Keys

Use a passphrase to generate one-time passwords.

Server generates a new password each time an authentication request is made.

Client software that acts as a one-time generator is used on a workstation to generate the same password when the user enters the passphrase.

Since both systems know the passphrase, and both systems are set to the same number of times the passphrase can be used, both systems can generate the same password independently.

Sequential Key Authentication Process

The user enters a passphrase.

The client issues an authentication request.

The server issues a challenge.

The generator on the client and the generator on the server generate the same one-time password.

The generated password is displayed to the user for entry or is directly entered by the system. The password is used to encrypt the response.

The response is sent to the server.

The server creates its own encryption of the challenge using its own generated password, which is the same as the client’s. The response is evaluated.

If there is a match, the user is authenticated.

Sequential Key Authentication Process

Certificate-based Authentication

A certificate is a collection of information that binds an identity (user, computer, service, or device) to the public key of a public/private key pair.

The typical certificate includes

Information about the identity

Purposes for which the certificate may be used

Serial number

Location where more information about the authority that issued the certificate may be found

The certificate is digitally signed by the issuing authority, the certificate authority (CA).

The infrastructure used to support certificates in an organization is called the Public Key Infrastructure (PKI)

Certificates Use Two Keys

Unlike symmetric key algorithms, where a single key is used both to decrypt and encrypt, public/private key algorithms use two keys: one key is used to encrypt, the other to decrypt.

If the public key encrypts, only the related private key can decrypt.

If the private key encrypts, only the related public key can decrypt.

Certificate-based Authentication Process

The client issues an authentication request.

A challenge is issued by the server.

The workstation uses its private key to encrypt the challenge.

The response is returned to the server.

Since the server has a copy of the certificate, it can use the public key to decrypt the response.

The result is compared to the challenge.

If there is a match, the client is authenticated.

Certificate-based Authentication Process

SSL/TLS

Secure Sockets Layer (SSL) is a proprietary certificate-based system that is used to provide authentication of secure web servers and clients and to share encryption keys between servers and clients.

Transport Layer Security (TLS) is the Internet standard version of SSL.

While both TLS and SSL perform the same function, they are not compatible.

SSL

In the most common use of SSL, an organization obtains a server SSL certificate from a public CA, such as VeriSign, and installs the certificate on its web server.

The organization could produce its own certificate, but a public CA certificate is automatically a part of Internet browsers so the identity of the server can be proven by the client.

SSL Authentication

The user enters the URL for the server in the browser.

The client request for the web page is sent to the server.

The server receives the request and sends its server certificate to the client.

The client’s browser checks its certificate store for a certificate from the CA that issued the server certificate.

If the CA certificate is found, the browser validates the certificate by checking the signature on the server’s certificate using the public key provided on the CA’s certificate.

If this test is successful, the browser accepts the server certificate as valid.

A symmetric encryption key is generated and encrypted by the client, using the server’s public key.

The encrypted key is returned to the server.

The server decrypts the key with the server’s own private key. The two computers now share an encryption key that can be used to secure communications between the two of them.

SSL Authentication

Smart Cards

The protection of the private key is paramount in certificate-based authentication.

If an attacker can obtain the private key, they can spoof the identity of the client and authenticate.

Smart cards can be used to require that the private key be protected and separate from the computer.

Smart Card Authentication

The user inserts the smart card into the reader (or moves it close to the scanner).

The computer-resident application responds by prompting the user for his unique PIN. (The length of the PIN varies according to the type of smart card).

The user enters his PIN.

If the PIN is correct, the computer application can communicate with the smart card. The private key is used to encrypt some data. This data may be a challenge, or it may be the timestamp of the client computer. The encryption occurs on the smart card.

The encrypted data is transferred to the computer and possibly to a server on the network.

The public key (the certificate can be made available) is used to decrypt the data. Since only the possessor of the smart card has the private key, and because a valid PIN must be entered to start the process, successfully decrypting the data means the user is authenticated.

Extensible Authentication Protocol (EAP)

Allows pluggable modules to be incorporated in authentication process.

Authentication interfaces and basic processes can all remain the same, while changes can be made to the acceptable credentials and the precise way that they are manipulated.

New algorithms for authentication can be added as they are developed.

Authentication modules used with EAP are called EAP types.

EAP/TLS: Uses the TLS authentication protocol and provides the ability to use smart cards for remote authentication.

EAP/MD5-CHAP: Allows the use of passwords by organizations that require increased security for remote wireless 802.1x authentication but that do not have the PKI to support passwords.

Biometrics

Facial recognition and identification

Retinal scans

Iris scans

Fingerprints

Hand geometry

Voice recognition

Lip movement

Keystroke analysis

Biometric Disadvantages

Accuracy is judged by the number of false rejections and false positives that it generates.

Biometrics live under the shadow, popularized by the entertainment industry, with malicious attackers cutting body parts from a real person and using them to authenticate to systems.

The gummy finger attack: In May 2002, Tsutomu Matsumoto obtained an imprint of an audience member’s finger and prepared a fake finger with the impression. Using $10 worth of commonly available items to produce something the texture of the candy gummy worms, he defeated ten different commercial fingerprint readers.

Matsumoto also successfully used latent fingerprints from various surfaces.

Additional Uses for Authentication

Computer authenticating to a central server upon boot before the computer is allowed to have access to the network

Computer establishing a secure channel for network communication

Computer requesting access to resources

Authorization

Specifies what the user can do

User Rights

Privileges or user rights are different from permissions. User rights provide the authorization to do things that affect the entire system, such as create groups, assign users to groups, and log in to a system.

Other user rights are implicitly granted to default groups.

Role-based Authorization (RBAC)

Users are allowed access to specified data or allowed to run certain applications.

Commonly, roles are assigned by departments such as Finance, Human Resources, Information Technology, and Sales.

Users are added to groups that have specific rights and privileges.

Access Control Lists (ACLs)

ACLs determine whether the requested service or resource is authorized.

Windows File-access Permissions

The Windows NTFS file system maintains an ACL for each file and folder.

The ACL is composed of a list of access control entries (ACEs). Each ACE includes a security identifier (SID) and the permission(s) granted to that SID.

Permissions may be either access or deny, and SIDs may represent user accounts, computer accounts, or groups.

ACLs for Network Devices

ACLs are used by network devices to

control access to networks

and

control the type of access granted

Routers and firewalls may have lists of access controls that specify which ports on which computers can be accessed by incoming communications, or which types of traffic can be accepted by the device and routed to an alternative network.

Rule-based Authorization

Rule-based authorization requires the development of rules that stipulate what a specific user can do on a system.

These rules might provide information such as “User Alice can access resource Z but cannot access resource D.” More complex rules specify combinations, such as “User Bob can read file P only if he is sitting at the console in the data center.”

In a small system, rule-based authorization may not be too difficult to maintain, but in larger systems and networks, it is excruciatingly tedious and difficult to administer.

Summary

Authentication is the process of proving you are who you say you are.

While many modern systems are based on hardware, such as tokens and smart cards, and on processes that can be assumed to be more secure, such as one-time passwords, most systems still rely on passwords for authentication.

Authorization determines what an authenticated user can do.

User rights are often provided directly by the operating system, either via permissions granted to the user account directly, or through the use of groups.

Role-based access controls are similar to group authorization, but they are organized into sets of functions based on some key common characteristic.

Access control lists, in which specific, granular capabilities are individually specified, are also used to authorize functions.