Authentication in Applications

Authentication is the act of establishing identity via the presentation of information that allows the verifier to know the presenter is who or what it claims. This identity could be any number of things, including:

• People
• Systems
• Applications
• Messages

Why would one want to verify an identity in the first place? Hopefully, most people reading this recognize that as sarcastic humor. If not, here are a few common reasons:

• To control access to a system or application
• To bind some sensitive data to an individual, such as for encryption
• To establish trust between multiple parties to form some interaction with them
• To assure that a piece of information is genuine

Within an application, one or all of these aspects may apply. This article presents different types of authentication and ways of adding it to your applications.

Types of Authentication

There are many different types of authentication that can be used in an application. The selection of the most appropriate type of authentication will depend on the needs of the application; use this guide to determine which makes the most sense for your application.

• Basic, single-factor authentication
• Multi-factor authentication
• Cryptographic authentication

These authentication types apply to all classes of entity that require authentication: systems, users, messages, and applications.

Basic Authentication

Basic authentication is a commonly used term that most people probably understand already. It refers to password-based authentication. A password can be any information that is used to verify the identity of a presenter. Common examples that fall into this category are:

• The common password
• Host or system names
• Application names
• Numerical IDs

Authentication entails the validation of a single credential pair—the presenter’s identity reference and their password. The authentication process typically takes the password and compares it to that which is stored in the authentication database. This comparison is often done as a plain text comparison where the provided password exactly matches that expected password, or with some permutation function where the password first undergoes an alteration such as hashing or encryption and the resulting data is then compared. The storage of the password is the next piece that is also often in plaintext or some permutation based on the aforementioned cryptographic function. Basic authentication has the following benefits. It is:

• Easy to manage within an application
• Easy to deploy across applications
• Easy for end users to use

There are some important caveats when using basic authentication of which every developer should be aware:

• Passwords are commonly weakly specified
• Identities can be spoofed and impersonated
• Passwords can be susceptible to theft
• Requires considerable effort to provide strong security
• Can be difficult to scale across distributed and large environments

Basic authentication often entails the transmission of a name (username or system name), and the password, which can be easily stolen and compromised if they’re transmitted unprotected across the network. Here are some of the ways to increase the strength of Basic authentication:

1. Use digest authentication—hash or encrypt the password prior to transmission
2. Use pass phrases (longer passwords) and set minimum password lengths
3. Enforce the usage of diverse character sets that include alpha-numeric, special characters, and mixed-case passwords that are not in a dictionary
4. Add security to the connection wherein the password is not transmitted in the clear across the network, such as TLS/SSL
5. Do not store passwords in plaintext in whatever mechanism is used—database, file system, directory

Multi-Factor Authentication

Multi-factor authentication is the use of a combination of authentication methods to validate identity. The most commonly used description of multi-factor authentication is the use of information that is known only by the person, combined with something in his or her possession. These are typically:

• The name and password
• Some form of token

A token is a hardware component that is used during the authentication process; it typically provides another piece of information that cannot be ascertained without physical control of the token. Different types of tokens used in multi-factor authentication are:

• Smart cards
• One-time password/phrases
• Single-use PINs or pseudo-random numbers
• Biometric information

Multi-factor authentication provides the following additional benefits:

• Difficult to spoof and impersonate
• Easy to use

As security components are layered, the complexity also rises. The following potential drawbacks are had with multi-factor authentication—each environment is different; therefore, the influence of these on the decision-making process will vary:

• Deployment can be difficult
• Tokens easily can be stolen
• Management of the tokens can be challenging, especially in the event of lost or stolen tokens

Cryptographic Authentication

The final form of authentication outlined here is that which utilizes cryptography. This includes the following forms:

• Public Key Authentication
• Digital Signatures
• Message Authentication Code
• Password permutation

Public Key Authentication

Public key authentication occurs when the owner of a key pair (private and public) communicates the public key, in some form, to the authenticating party, at which point it is verified to be true. There are a couple of methods for public key authentication worth discussing:

• The use of the public key itself
• Public key certificates

To verify the identity of the presenter of the public key, a nonce is encrypted using the public key. If the nonce can be decrypted and returned to the sender, that means the owner of the public key also has possession of the corresponding private key.

The use of public-key certificates builds on this relationship between the public and private key. Verification of a public key, alone, may indicate that the identity is as expected, but there is still a bit missing—trust. How does one know whether the party presenting the keys has not stolen them from the legitimate owner? Also, just because a person, system, or application may be truly who or what it says it is, how does the authenticating party know it can or should trust it? A public key certificate adds a trust relationship between a mutually known and trusted third party. The certificate is created when a mutually trusted third-party signs a public key with its own key. The authenticating party then can verify the identity of the presenter’s key and also know that it can be trusted because of the shared relationship with the certificate signer. In the event that the keys are stolen, the trusted third party easily can revoke its trust of the keys and notify its trustees that they are no longer trustworthy.

Digital Signatures

Digital signatures are another piece of the cryptographic puzzle. A digital signature is made when the owner of a key pair (an individual or a system) uses its private key to “sign” a message. This signature can be verified only by the corresponding public key.

This is most recognizable with the signed public key certificate—wherein the Certificate Authority, or trusted third party, signs a public key. The party doing the authentication can verify that the presenter of a public key has possession of the private key, and that a mutually trusted party vouches that the holder of the key is true. Digital signatures are also commonly used on messages such as e-mail, so that the recipient can have some trust that the e-mail message was sent by the person they expect.

Message Authentication Codes (MACs)

A message authentication code is created when a secret key is used in combination with the message or information to be proved authentic. The MAC can be generated by using a hashing algorithm or symmetric encryption. MACs can be used to provide integrity verification as well as authenticity to those possessing the secret key.

Password Permutation

I cannot discuss cryptographic methods without showing the relationship to basic authentication and its differences. As discussed above, in basic authentication, many passwords are typically encrypted or hashed, and then during the process of authentication, the password goes through the same transformation as that which is stored and then compared. This should not be confused as a method of strong authentication simply because of its use of cryptographic functionality (hashing, encryption). Password schemes are still weak because the cryptography used is only for the storage and comparison piece, but has no relationship to the presenter’s authenticity. They are easily stolen and impersonated.

Collaboration Between Authenticating Entities

With the widespread creation and deployment of distributed applications, authentication is critical, but also requiring some attention is the concept of Single Sign-On (SSO). Single sign-on is the mechanism that allows a person, system, or application to identify itself and be authenticated once and, through various methods, have that authentication work across all other related components and applications. A simple example is an application that authenticates a person at the Web interface and then uses the provided credentials to transparently authenticate the person at all other applications within the service. Single sign-on can be done in any of the following ways:

• Simple transparent caching and re-use of provided credentials
• Stateful session information such as cookies and tokens
• Complex authentication services such as Kerberos

The goal of single sign-on is to increase ease-of-use while maintaining some higher degree of security. In cases where different applications are used to provide a single service, the lack of single sign-on could require an individual or application to go authenticate several times to receive a desired service. A more easily used service is one that allows an entity to authenticate once at the outset and transparently gain access to all of the applications required to provide the intended service, on demand.

If several different applications are being hooked together to provide a single service, and if each requires some level of authentication, single sign-on may be a valuable component. Common architectures for single sign-on include proxying authentication information and generating stateful session information.

Proxying authentication information means that one or more applications are caching that data. This has the following potential pitfalls:

• Multiple copies of sensitive credential data are in memory, in different locations and subject to compromise.
• Does not easily handle the case where authentication information differs at each juncture in the service.
• Does not reflect a tight integration between related applications and introduces weaknesses at each level, including identity spoofing and theft of credentials.
• Caching of data must handle synchronization safely, or be susceptible to cache corruption and stale information.

Stateful session information is information that has the following aspects:

• Is generated as a result of successful, initial authentication
• Can be verified
• Can be trusted
• Maintains sequencing to avoid insertion, replaying and spoofing

This means that an entity authenticates at the start of a session, and as a result some form of information is generated—this could be a cookie or token—which then can be uniquely identified and verified to have been generated by a known trusted component that is part of the service. This token information then can be passed around to all applications as needed and verified.

Applications and Authentication

Now that the overview of various authentication methods has been outlined, you can take a look at its use in the applications. The following application-specific areas will be covered:

• Identifying what needs authentication
• Choosing the appropriate authentication method(s)
• Guidelines for implementing authentication

Identifying the Need for Authentication

The following questions help the application designer and developer understand whether there is a need for authentication within their application:

• Are there multiple users or applications that will interact with the application in question?
• If multiple entities are expected, will they all access exactly the same data, configuration, and information, or will each have its own set of information, regardless of how small?
• Is the application running in a completely closed and trusted area, wherein there is no person, system, or application that will access it from untrusted parts—such as the Internet, other networks, or unknown applications?
• Is there a concept of privileged information or functionality and the separation or isolation of this within the application?

If the answer to any of these questions is “yes,” authentication is needed within the application.

Choosing the Appropriate Authentication Methods

Usually, deciding if authentication is necessary is the easy part. Deciding how to perform authentication quite easily can become a difficult path. This section covers an overview of architectural frameworks for providing authentication. The following high-level options for authentication are available:

• Internal or local service-based authentication
• External service-based authentication and integration

Local Authentication

There are several reasons, or combinations of reasons, that may warrant implementation of local, internal authentication within an application:

• Stand-alone application
• No or intermittent communication capabilities
• Limited, small, or embedded applications
• Restricted application resources

If one chooses to have an application utilize its own authentication mechanism, there are several common examples:

• Implement a proprietary authentication scheme, based on standard methodologies
• Rely on the services of the local operating system, if available
• Utilize available libraries for providing authentication functionality

The implementation of one’s own proprietary scheme is generally not recommended because there are many potential risks to a home-grown method, unless it has the benefit of expert research and analysis. If a proprietary scheme is absolutely necessary, it should ideally rely on the use of standard security technologies; examples are encryption and one-way functions, protocols, and formats—all of these technologies have been well vetted and are available for everyday use.

Most Operating Systems also have implementations of local authentication services. These include some of the following:

• Pluggable Authentication Modules (PAM)
• Unix/Windows authentication
• File-based authentication

Finally, as hinted above, when implementing authentication features in an application, from-scratch implementation of standard-based technologies should be avoided. There are several encryption libraries available, the most notable of which is OpenSSL (http://www.openssl.org), as well as those provided by the Operating System. More will be explained further in the article.

External Service-based Authentication and Integration

It is often desirable that an application co-exist with other applications and share common information, including authentication information. The selection of internal and/or local authentication can quickly preclude an application from integrating easily with an existing environment. Also, enterprise applications, or those that need to work within an enterprise environment, will likely need to rely on the services present, which include enterprise authentication. Authentication services at the global and enterprise levels often are part of larger directory structures and services. These include:

• LDAP
• Active Directory
• NIS/NIS+
• Kerberos

To work with these services and already installed environments, applications will have to make use of various libraries and interfaces to work with these systems and infrastructure. There are existing libraries for all of these services, in many different programming languages, that allow an application to work directly within the specific framework.

If an application designer wants to work with standards-based and accepted authentication and other security services, it may be important to avoid a tight integration to one particular service or another. To leverage existing services and maintain flexibility, an application designer can look toward defined standards for general-purpose security services. The GSSAPI—the Generic Security Services API, is an defined set of standards that allows for a common interface to express security services—see RFCs 2743, 1509, and 1964 for further information. There exist GSSAPI bindings for the following authentication and security services, among others:

• Kerberos
• Active Directory
• LDAP

Another flexible framework is SASL, Simple Authentication and Security Layer. SASL is defined in RFC 2222. SASL provides a standard way to secure authentication across network channels. SASL works by defining a standard API with support for accessing numerous “mechanisms”—these are the defined series of challenges and responses for authentication, including the following:

• Basic authentication with cleartext passwords
• Hash-based authentication
• One-time passwords and keyed PINs
• Kerberos, via GSSAPI
• Custom-defined authentication schemes

These APIs allow application designers to standardize on a common interface for managing security services such as authentication. This allows the application to more easily extend functionality to support new and different authentication methods, as well as to integrate different security services together in a uniform way as the application and its deployment grows.

Guidelines for Implementation

This section covers some general guidelines that are helpful during implementation of authentication services. The guidelines are organized into the following sections:

• Approaches to sensitive data
• Security strength versus business factors
• Usability

Approaches to Sensitive Data

Sensitive data refers to any information that is used for authentication or that could be used to the detriment of the application, system, or environment if compromised. The proper handling of sensitive data can quickly increase or decrease the strength of an application. Sensitive data—which may include passwords, keys, or other personal information—can easily be used throughout the internals of an application and become unmanageable. Different internal aspects include:

• In-memory manipulation and storage of data
• Persistent storage
• Message passing—IPC, RPC, network communication

To manipulate data objects, structures, and variables that deal with sensitive information, the rule of thumb is to isolate and limit the use of the data and clear it as soon as operations are done. Isolation is often more difficult to achieve with current memory management, but could be achieved via separate processes and threads, as is commonly seen with privilege separation in applications. Limiting the use of sensitive information means working to keep it around for only as long as necessary. The most common example is the storage of clear-text passwords and credentials in variables. This data is often transformed into some other form such as a hash or ciphertext prior to use. Once the transformation is complete, the memory should be cleared (zeroed) and freed. For those languages that treat strings as immutable objects, care should be taken to use non-immutable buffers and arrays for their storage instead.

Persistent storage presents another challenge when working with sensitive data. One should not consider their local disk or other persistent storage mechanism to be a safe location; this is one of the most common misperceptions—that a local storage device is secure because it’s inside of the system. The more correct philosophy to consider is that all local storage devices are easy ways for attackers to get your information. Therefore, if the information is sensitive and needs to be non-volatile, make sure it is done safely. This means encrypting data that needs to be reversed or viewed in plaintext, or hashing things that do not need to be viewed in plaintext. Also, for those bits of information that are encrypted, keys should ideally be stored elsewhere and not on the same storage device. There are also secure hardware devices for storing sensitive information. These include the tokens discussed above, as well as hardened devices meant explicitly for securely storing data.

Message passing with sensitive information should also leverage known-secure protocols. Network communications, especially, can be secured with protocols such as TLS/SSL. Inter-Process Communication (IPC) and Remote Procedure Calls (RPC) can be treated as network protocols, even if they are communicating on the same physical system. Eavesdropping on communications between processes can be done just as easily as that which is done over the network.

Security Strength Versus Business Factors

When deciding on an authentication mechanism, the natural pressures of deliverables, schedules, and customers can cause difficult decisions that often leave security out of the picture. The following table provides an easy comparison of the following aspects:

• Ease of implementation: This is how simple or complex the implementation can be, taking into consideration the availability of libraries and standards.
• Ease of management: The complexity of managing the authentication environment, considering users, addition, and removal of users, updating of credentials.
• Ease of deployment: The complexity of deploying the authentication technology across simple and advanced environments, considering hardware and software requirements.
• Strength: The overall security strength, considering methods of attack and compromise and inherent weaknesses, scalability over large environments.
• Risk: The correlation of other columns to generally categorize the risk the technology poses to an environment or organization. Considers historical weaknesses, availability of tested implementations and libraries, likelihood of attack.

This information is the general case, and obviously the type of application and its other traits, as mentioned in this article should be considered when determining the most appropriate authentication technologies.

Usability

One of the most commonly discussed factors with the implementation and use of security technology is the issue of usability. Usability can be considered from two angles:

• External interaction
• Internal manageability

External interactions refer to any involvement that a user, system, or other application may have with the application. The following list presents some of the areas where usability of authentication should be considered:

• Burden—the ease or difficulty of self-management that is placed on the intended user, system, or application; includes:
• Memorization of highly-constrained passwords
• Frequency of changes/expiration
• Method to recover or reset lost/stolen passwords
• Ease of use for hardware tokens, methods of recovery for lost and stolen items
• Initialization of new credentials including keys
• Certificate acquisition and revocation process

The following list provides a set of items to consider for usability as they relate to internal manageability of authentication—several of which are issues that affect external interaction (above) and internal management:

• Managing credentials
• Additional users, systems, applications
• Response to compromise, expiration
• Storage of credentials
• Deployment of tokens, hardware, and other peripherals
• Cost
• Registration
• Results of loss, replacement, damage
• Key management for the application and servers
• Key generation
• Certificate generation
• Expiration, revocation
• Certification Authority
• Secure storage of keys
• Software implementation
• Library availability
• Ease of usage
• Complexity of software updates, backward compatibility

Use these items as a guide to help choose and design the most appropriate authentication solution for your application. The manageability of the technology and the authentication environment are as important as the strength of the security components; when usability is not considered, the ways in which the technology is used often ends up unpredictable and security will suffer as a result.

Risk Management, Authentication, and Security

The heart of security revolves around risk management. This means understanding the environment in which an application runs, the vital assets and aspects of the organizations that use the application, and the needs of the application itself, given the types of data and information with which it works.

Choosing the appropriate authentication mechanism is as much to do with technology as it is an understanding of the risks that need to be managed. Looking at what is being protected, from whom and by whom, and the effects of a failure in the security or if there wasn’t any authentication can provide the necessary perspective for strong security decisions.

This article covers the primary types of authentication, their use, caveats, and recommendations for implementation in applications. The guidelines and information about strength, usability, and balance of business needs with security can help application designers make logical and safe decisions with regards to their applications.

About the Author

Chad Cook has spent over a dozen years in Information Security that include both product engineering and IT services. Chad has developed IT service security strategies, networks and policies for organizations including BBN and GTE Internetworking, Infolibria, and the international security consulting firm, @stake/Symantec. He has architected and developed security technology for award-winning networking, security, and financial products sold worldwide, including core routers, edge devices, utility hosting systems, Web services security devices, and high-performance systems. Chad has nine patents applied for and pending on risk analysis, simulation and modeling techniques, and encryption processing and acceleration.

Currently, Chad is the VP of Information Security at Lime Group, a New York securities and brokerage organization, where he leads product architecture, infrastructure security, and compliance efforts. Prior to Lime Group, he designed and developed security risk management and threat modeling products as CTO at Black Dragon Software. Chad has held lead engineering and security positions developing products at BBN, GTE, and a number of small companies. Chad is an internationally published author on security topics, having contributed to two books, Maximum Security, 3rd and 4th editions, has been featured in numerous articles and also has written articles for Symantec’s SecurityFocus.com, Developer.com and numerous online publications.

A frequent speaker, Chad has spoken at NATO and United Nations forums on security, numerous conferences, analyst’s events, and security summits.