Security+ Course – 4.2 Authentication

1. Authentication Factors

Once you’ve identified yourself to a system, you must prove that claim of identity. That’s where authentication comes into play.

3 different authentication factors

1. Something you know: this is the most common and is typically in the form of a password the user has to remember. Users should choose strong passwords consisting of as many characters as possible and combine characters from multiple classes such as uppercase and lowercase letters, digits, and symbols
2. Something you are: Biometrics measure one of your physical characteristics such as a fingerprint, eye pattern, voice print, or facial geometry
3. Something you have: This requires the user to have physical possession of a device such as a smartcard or authentication token key fob

Errors in Authentication Systems

The strength of techniques used by each of these authentication factors may be measured by the number of errors that it generates.

There are 2 basic types of errors:

1. False acceptance errors: these occur when the system identifies an individual as an authorised user and grants access that should be denied. This is a very serious error. The frequency of these errors is measured by the False Acceptance Rate or FAR
2. False Rejection errors: these occur when an authorised user attempts to access a system but is incorrectly denied access. This is not as serious as False Acceptance Errors and is it does not comprise the confidentiality of the system, but it is serious in that it does not give users access to resources they need. The frequency of these errors is measured by the False Rejection Rate of FRR.

2. Multi-factor Authentication

The authentication methods discussed previously are good, but they have their drawbacks.
What if someone steals a user’s password through a phishing attack? Once they have the password they can assume that users identity
What if someone loses their smartcard? An attacker could find it and use it assume that users identity.

The solution to this issue is to combine authentication techniques from multiple factors. This is known as multi-factor authentication.
Some examples include:

• using a smart card and a password together (this combines “something you have” and “something you know”)
• Using a fingerprint reader and a PIN (This combines “something you are” and “something you know”)

EXAM TIP: you will likely find a question on this in the exam. Make sure to pick an example that uses techniques from 2 different factors.

3. Something You Have

Tokens

Traditionally organisations implemented Something You Have authentication using physical tokens like this one pictured:

They’re small hardware devices that the user typically carries on a keychain. When the need to authenticate arises, the user first provides a username and password, satisfying the something-you-know criteria. The system then prompts the user to provide an authentication code. The user pulls out his or her token and presses the button. The token then displays a code that the user enters into the system, proving physical possession of the token and completing the authentication sequence. The cost of providing thousands of users with physical tokens can add up quickly.

Soft Tokens

The rapid spread of smart phones led to the adoption of soft-token technology. Soft tokens are simply apps that run on a user’s smartphone, such as the Google Authenticator app. Soft tokens generate a constantly changing series of codes. When an authentication system prompts the user to enter a code from the token, the user simply opens the app and reads off the current code.

One Time Passwords (OTPs)

There are two different protocols for generating these codes:

1. HTOP: The HMAC-based one-time password algorithm, HOTP, uses a shared secret and an incrementing counter to generate the code displayed on the token. The code changes whenever the button is pushed, and the code is valid until it is used
2. TOTP: The time-based one-time password algorithm, TOTP, doesn’t use a counter. Instead, it uses the time of day in conjunction with a shared secret. This means that the code changes constantly and is only valid until the token generates the next code. The token and the authentication system must have synchronized clocks for TOTP to function correctly. The Google Authenticator soft token uses TOTP.

Smart Cards

This is another way of providing Something You Have. We discussed these previously.

4. Password Authentication Protocols

One of the most common applications of password security is to secure virtual private networks and other remote access technologies.

Password Authentication Protocol (PAP)

This is the earliest of these protocols. In this protocol, the client wishes to authenticate to a server, and both the client and server know the user’s password.

The client simply transmits the username and password to the server, and the server validates the password. That’s about as simple as it gets and successfully implements password authentication. But there’s one major flaw to this protocol. PAP does not use any encryption to protect this communication. Anyone able to eavesdrop on the connection can read the username and password right off the network. For this reason, PAP should not be used, except under circumstances where the transmission is encrypted by other means.

Challenge Handshake Authentication (CHAP)

In CHAP, both the client and the server have prior knowledge of a shared secret. Neither wishes to transmit that secret over the network, because it would compromise the security of the system. Instead, they work through a process where they prove to each other that they both know the secret without actually exchanging the secret value over the network.

Here’s how it works. Once they establish the link, the server sends a random value to the client. This is known as the Challenge value. When the client receives the challenge, it combines the challenge with the secret and computes a cryptographic hash of the two values. This hash is irreversible, meaning that it is not possible to retrieve the input if you have the hash output. The client then transmits the hash value to the server. This is known as the Response value.

The server receives the response and stores it in memory. The server then computes its own hash value by using the same hash function on the challenge it sent to the client and the shared secret that they both know. The server then compares the response it computed with the response received from the client. If the two values match, the server knows that the client’s secret is identical to the server’s secret. And it authenticates the client without ever having to send the actual secret password over the network. CHAP is a much more secure alternative to PAP and an acceptable technology for use in modern secure applications.

Microsoft CHAP (MS-CHAP)

Microsoft created their own version of the CHAP protocol and called it MS-CHAP for Microsoft CHAP. They later released a second version of the protocol called MS-CHAPv2. It’s important to note that security researchers have found significant vulnerabilities in both versions of MS-CHAP, and these protocols are now considered insecure.

5. Single Sign-on and Federation

Identification and authentication can be an annoying process for end-users, and difficult to manage for organizations. The concepts of Federation and Single Sign-On seeks to reduce some of this burden.

Federated Identity Management

•  a single individual may have accounts across a wide variety of systems
• Federated Identity management systems share identity information
• This reduces the number of individual identities a user must have

Examples of Federated Identity Management systems

• Google Federation
• Facebook Connect
• Twitter Accounts

Single Sign-On (SSO)

SSO goes a step further and shares authenticated sessions across systems. In an SSO approach, users log on to the first SSO-enabled system they encounter, and then that logon session persists across other systems until it reaches its expiration time. If the organisation sets the expiration period to the length of a business day, it means that users only need to logon once per day, and then their single sign-on will last the entire day.

Shibboleth is an example of an SSO that was created by Universities to resolve their identity management issues.

Trust Relationships

Trust relationships across different authentication domains are described in terms of their direction and their transitivity.

Types of Trust Relationships-

6. RADIUS and TACACS

One of the most common access control needs is for an organisation to have a centralised approach to network and application authentication, authorisation and accounting.

RADIUS

Remote
Access
Dial
IN
User
Service

As the name implies, RADIUS was first used to authenticate the users of modem-based dial-in services back in the 1980s and 1990s. A centralised RADIUS server could support modem pools located around the country, providing a single point of administration for password and account management, and consolidating accounting records in a centralised location.

RADIUS is used today to allow many diverse applications to reply upon the same authentication source. Here is an example of a successful RADIUS authentication on a wireless network.

1. The end-user attempts to connect to a wireless access point
2. The access point serves as the client in the RADIUS request, passing a request for authentication to a RADIUS server
3. The RADIUS server then checks with an external authentication source, such as an active director or LDAP server to determine whether the user’s password is correct
4. If the password is correct, the RADIUS server sends an access accepted message back to the wireless access point, which allows the user on the network. If the password is incorrect, the RADIUS server sends an access rejected message back to the wireless access point, which denies the user access to the network.

EXAM TIP: be sure that you understand the concept of a RADIUS client and server when you look at it from an application perspective. Remember the RADIUS client may actually be an application server

RADIUS Disadvantages

• It uses the User Datagram Protocol (UDP) which reduces its reliability
• While it does provide cryptographic protection for the password, most of the data sent in a RADIUS connection is unencrypted, requiring the use of additional security measures

The Terminal Access Controller Access Control System (TACACS)

This is an alternative to RADIUS and performs a similar function. First developed in the 1980’s there are two early versions of TACAC rarely used today. The current TACACS standard is the TACACS+ protocol developed by CISCO. It has two improvements over RADIUS:

• It uses the connection oriented and reliable Transmission Control Protocol (TCP) instead of the less reliable UDP
• It fully encrypts the entire authentication session

7. Kerberos & LDAP

Kerberos

The Kerberos access control system is widely used to implement authentication and authorisation systems on both UNIX and Windows platforms. It is one of the core protocols underlying Microsoft Active Directory. Kerberos is a ticket-based authentication system that allows user to authenticate to a centralised service and then use tickets from that authentication process to gain access to distributed systems that support Kerberos authentication.

Kerberos is a complex service but it is important for the Security+ exam

There is a good video explaining Kerberos here: https://www.youtube.com/watch?v=2WqZSZ5t0qk

Lightweight Directory Access Protocol (LDAP)

LDAP is an important protocol to access control. It allows services on a network to share information about users and their authorisations in a standardised, open format. Active Directory uses LDAP in combination with Kerberos. While Kerberos handles authentication, LDAP provides the means to query information stored in the directory service.

Ports

– Kerberos port 88
– LDAP port 389
– Secure LDAP port 636

NTLM Authentication

This is the older windows authentication, pre Kerberos.
– Was widely used on many Windows systems
– Depends on a hash based challenge response protocol
– Has serious security vulnerabilities-Weak Encryption
– Pass the Hash: allows the use of credentials from one system to gain access to another system

Avoid the use of NTLM!!!

8. SAML

Security Assertion Markup Language, SAML, allows browser-based single-sign-on across a variety of web systems.

There are three actors in a SAML request:

1. Principal: the end user trying to access a service
2. Identity Provider (idP): this is the organisation providing proof of identity. Usually the users employer, school etc…
3. Service Provider (SP): the web based service the user is trying to access

How SAML works:

1. the end user, principal, requests access to a resource from the service provider
2. the service provider redirects the user to the single-sign-on service from the user’s identity provider
3. The user then tries to authenticate to the identity provider using a user name and password or other authentication technique. The key here is that the user must authenticate directly to the identity provider
4. The identity provider then creates an XHTML form customized for the service provider
5. The user then has to use this form to request what is called a security assertion from the service provider. This assertion request includes proof of identity from the identity provider
6. The service provider then validates the request and creates a security context with the desired service and redirects the user to that service
7. The user then requests that desired service and the resource service responds by granting access

Benefits of SAML

1. After the user authenticates once to the identity provider, that authenticated session may last for a period of time specified by the identity provider. During that time period, the user does not need to reauthenticate, providing a true single-sign-on experience.
2. The service provider may use the identity provider’s authentication without gaining access to the user’s password, which remains a shared secret between the user and the identity provider.

9. OAUTH and OPENID Connect

These protocols provide a federated single sign-on experience for the web.

Oauth (Open Authorisation)

This doesn’t actually authenticate, it authorises. It is a protocol designed to work across a variety of web services.

Oauth Providers:

• LinkedIn
• Facebook
• Google
• Amazon

How Oauth works

In this example we will login to the training site Lynda.com using LinkedIn credentials

1. When you go to the Lynda sign in page there is a button to “sign in with LinkedIn”. When you click on this it brings you to a Linked page. You can see “oauth” the web address-
   
2. This is a secure site that asks you to login to your LinkedIn account. At this stage it might ask your permission for Lynda.com to access some parts of your LinkedIn profile
3. Once you login it returns you to Linday.com and you are logged in. Lynda.com never sees your login credentials.

OpenID Connect

This is an identification and authentication protocol designed to work with Oauth.

10. Certificate Based Authentication

Digital certificates may be used for authentication. Among other uses, they may be used to connect to servers by SSH, to power smart cards, and for restricting network access to specific devices. When you use digital certificates for authentication, you create a digital certificate similar to the one used to secure websites. The certificate’s purpose is to provide a trusted copy of a public key to third parties. You retain the corresponding private key to prove that you are the owner of the public key in the certificate.

When you want to use keys for encryption, you first create a public/private key pair. You retain the private key as secret knowledge, and then share the public key with the server you wish to authenticate to.

Key-Based Authentication Process

1. you attempt to log in to a server using key-based encryption
2. the server generates a random message and sends it to you
3. You take that message and encrypt it using your private key, and then send the encrypted message back to the server
4. The server decrypts this message with your public key, and if it matches the original message, knows that you have access to the secret private key, proving your identity and authenticating the connection.

This provides basically the same level of protection as a strong password, but the major benefit of key-based encryption is that it can be automated. One server can connect to another using certificate-based authentication without someone entering a password.

Setting up a server with key based authentication

In the video he went through the tutorial of creating an Amazon server and using Key based authentication

1. Created the Linux server at the Amazon console
2. Selected to use “Key based authentication” when the option came up
3. Selected to create a new key pair. This then allowed him to download the private key
4. He then passed this key to the server when using SSH to connect to it

Certificate Authentication Uses:

• SSH Connections
• Smart Cards (CAC/PIV)
• Network access (802.1x