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