October 25, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Authentication in Applications

  • April 20, 2006
  • By Chad Cook
  • Send Email »
  • More Articles »

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.
Authentication Type Ease of Implementation Ease of Management Ease of Deployment Strength Risk
Basic Authentication Easy Easy Easy Low High
Multi-factor Medium Medium Medium to Complex Medium Medium
Cryptographic Medium Complex Medium to Complex Strong Low

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.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel