Security 101: Authentication (Part 2)

Welcome to part two of our three-part series on authentication. Rather than talking about theoretical authentication schemes, we will review some of those that are used in networks today.

Username/password

The most basic forms of authentication use username and password as the credentials for authentication. Everyone is used to this and almost everyone has problems keeping track of usernames and/or passwords. Many products and services will use a person’s email address as their username and many users will maintain the same password across multiple systems so it is easy for them to remember their cred. However, that also makes it easy for an attacker to figure out your username and if they get your password on one system they can then use it on others. Your bank may be very secure, but if a social media site is not and a hacker gets your creds from that, your bank accounts are now accessible to them without any need to circumvent the bank’s security. Let’s see how usernames and passwords are stored.

Flat file

The simplest form of username/password authentication goes against a flat file. Whether the file stores the creds in the clear, encrypted or hashed, it’s just a file and physical access to a system will enable an attacker to get that file and eventually crack it or simply replace it. Unix derivatives including Linux use this for local accounts in the /etc/passwd and/or /etc/shadow files. Windows systems store this in the registry but then copy to %SystemRoot%/system32/config/SAM. There are many ways to circumvent or capture these files if you have physical access to the machine and can boot from a USB key or CD/DVD. Applications and websites may store user information in a flat file.

Database

For enterprise systems, users’ credentials are stored in a database. The most widely used is Microsoft’s Active Directory, which is a multi-master database replicated across domain controllers. There are similar databases for other operating systems including Kerberos, Novell Directory Services (NDS) and LDAP. Applications and websites may also use a database to store credentials for users.

When a user must authenticate using username and password, there are many ways that the credentials can be passed to the system. If you are directly interacting with a process on your local system, you may just pass credentials directly to the app. But if you are accessing the app over the network, you need to ensure that credentials are passed securely using some form of encryption. Otherwise an attacker may be able to sniff them using a protocol analyzer.

Integrated

In an Active Directory environment, integrated authentication can be used. This leverages the user’s existing authentication to the environment so that the user does not receive a prompt when trying to access other resources. In essence, this is single sign on.

NTLM

NTLM authentication takes the user’s username and password and creates a hash, which is passed to a system (Domain Controller) for authentication. If the hash stored on the domain controller matches the hash passed by the user’s system, then authentication is successful. Traditional NTLM hashes have been calculated for billions of potential values in rainbow tables, and are therefore subject to easy compromise. NTLMv2 is a much more secure hashing algorithm and is not as vulnerable to compromise when captured on the network. However, if an attacker has the ability to download and run software on a Windows machine, they can conduct a “Pass the Hash” attack to get the logged-on users’ credentials. The attacker must already “own” a machine to conduct this attack. NTLM is still in common use to support legacy and non-Windows operating system integration.

Kerberos

Kerberos was specifically designed to protect authentication on a network where it is presumed that an attacker has the ability to sniff authentication traffic. It uses shared secrets between principals to obtain first a ticket-granting-ticket, and then to obtain session-granting-tickets for access to network resources. The shared secrets are typically passwords. It is the default authentication protocol in Windows networks today. See http://en.wikipedia.org/wiki/Kerberos_(protocol) for more on how Kerberos works. Kerberos can be vulnerable to the “Golden Ticket” attack, but this attack requires that an attacker already has admin rights on the domain, which is hard enough to get and damaging in its own right.

LDAP

LDAP authentication uses the lightweight directory access protocol to pass credentials to some LDAP service for authentication. Secure versions of LDAP use encryption to protect creds from being sniffed by an intruder. Windows supports an API called the GSSAPI that can encrypt credentials even when the LDAP protocol is in clear-text.

Now let’s look at how users can be prompted for and provide their username and password to systems.

Challenge

If you have visited website or tried to access a network resource and a pop-up prompts you for credentials, that is a form of challenge-based authentication. Challenge may use a hashing algorithm (integrated auth) or it may simply pass username and password to the system. Data encryption such as SSL must be used to protect credentials from sniffing.

Form-based authentication (FBA)

Websites use FBA to solicit credentials from users. Users type their username and password into fields on a webpage and POST them for further processing. FBA must use encryption (HTTPS) to protect creds, because the user is directly entering them without any hashing or other local protection.

Token

Token-based authentication can work with either Challenge or FBA to authenticate users against one system, which then issues a token for access to another system. This is commonly implemented in outsourced enterprise applications where the application provider relies on the customer to authenticate their users.

Two-factor authentication

We discussed 2FA in the earlier post, so here we’re just going to discuss the most common varieties. They may be combined with a PIN or even a full password, at the discretion of the admin implementing them, but in all cases require that the user have something physical to serve for authentication.

Certificate authentication

Certificate-based authentication uses a certificate in the possession of the user to prove identity. That certificate may be stored on the local machine in the certificate store or on a file, on a USB key or on a chip in a smartcard (see below.) In any event, the user must go through a process to prove their identity to the certificate authority, who then can issue a certificate to the user which will be trusted by whatever system requires the authentication. Certificate authentication is used for accessing networks (802.1x), websites and when used with smartcards, operating systems and internal applications.

Biometric

Biometric authentication relies on some physical attribute of the user. This can be a fingerprint, hand geometry, iris or retina scan, voice recognition or facial recognition. Some piece of hardware is required to capture the biometric data, which is then compared to a database for a match to authenticate the user.

Smartcard

Smartcards contain a chip that stores one or more certificates for a user. The user must know a PIN to unlock the chip before a certificate can be presented to an authentication request. Smartcards can be used for local authentication, network authentication and both internal and external application authentication. In the civilian world, smartcards are simply called smartcards, but in the US government space, they are referred to as a Personal Identity Verification (PIV) card and in the military as a Common Access Card (CAC.) Smartcards may also contain NFC, RFID and/or magnetic strips for use with other systems including various physical access and proximity systems.

One-time password (OTP) with PIN

The last common type of 2FA is the OTP token. These can be physical devices known as fobs, such as those from RSA or they can be software on mobile phones. In any event, OTPs generate a six- to eight-digit number that changes once every minute and that, when combined with a PIN, can be used to authenticate the user only during that brief time-frame. The numbers are not random, but have proven to be practically impossible to predict, requiring that the user have physical possession of the device to get the number, and to enter it along with a PIN in a very short timeframe. These are very popular in cases where hardware or software to read other factors, like smartcards or biometrics are not available.

In part three, we look at way to protect authentication. You can read part one here.