5. Implementing Authentication

This section describes and provides guidelines for implementing online authentication solutions. It provides detailed information on implementation options for the concepts covered in the earlier sections of this document and focuses on positioning towards an all-of-government approach.

Readers are reminded that any implementation should be undertaken using sound project management methodologies and with appropriate project audit in place.

Authentication Technologies

In spite of the many advances in computer hardware, software, and encryption there are relatively few techniques available to authenticate an individual. We can generally class the techniques as members of one of three groups:

• Secret - Something you know;
• Biometric - Something you are; and
• Token - Something you have

Each of these groups has subgroups as well.

Secret

The oldest and most pervasive authentication technique is the Shared Secret. An entity proves its identity to an authenticating party by demonstrating that they and that party both know a common or shared secret.

Secret Type I (Shared Secret)

Secret Type I authentication requires two parties to share a common secret. The authentication is performed by the party wishing to be authenticated sending a secret to the authenticating party. The authenticating party checks that the secret is the same as the secret registered for that party and grants or denies authentication accordingly.

This type of authentication is distinguished by the fact that both parties must know the shared secret before authentication can be performed (although it is often modified using a one way transformation before storage by the authenticating party).

Usernames and passwords are the most common form of Type I shared secrets and by far the most common form of authentication used on computer systems today.

The greatest flaw of this type of authentication lies in the fact that the first entity must communicate or transmit the shared secret and therefore lose control of it. The secret may be susceptible to interception during transmission, by suborning the authentication party or by another party masquerading as the authenticating party.

Type II secret authentication requires the first party, the party wishing to be authenticated, to have a secret. The second authenticating party, does not have the secret, but rather has other information that is mathematically related to the first party's secret. This related information does not disclose anything about the original secret, but does allow someone to prove if the secret has been used.

The common example of Type II Secret Authentication employs Public Key cryptography.

Biometric

Biometric authentication uses the physical characteristics of an individual to prove their identity. Like secret authentication, there are two general classes of biometric authentication.

Biometric Type 1

This type of authentication includes voice and handwriting recognition. The feature that distinguishes Type I Biometrics is that the physical characteristic being measured can easily change; for instance a person's voice may change significantly due to health conditions or emotional state.

Biometric Type 2

This authentication technique uses those physical characteristics of a person that do not generally change. Type II techniques include, fingerprint or face recognition, iris and retina scanning and hand geometry measurement.

Token Authentication

This is where an individual must present a physical token to prove their identity. Passports, drivers licenses and credit cards are typical tokens used with this type of authentication. Tokens generally incorporate some anti-counterfeiting features such as watermarks or other features that are difficult to reproduce. Note that not all types of tokens are useful in electronic authentication systems.

Portable electronic devices including USB flash drives, smart-cards, or PCMCIA cards are considered to be authentication tokens. In fact, these devices are really just storage devices used for Secret Authentication (typically Secret Type II). The advantage of these devices is that they typically provide relatively secure storage for the secret and resistance against brute force attacks. Some token devices also incorporate a digital signature as an anti-counterfeiting feature.

Another type of token is the time-based authentication token for one-time reply to a computer generated one-time challenge. The token being protected by a PIN and allocated to a specific user for additional security.

Usernames and Passwords

Usernames and passwords are the most common technique used for authentication in online transactions and require a closer examination.

The technique has both good and bad features:

• Good features include:
  • most people understand and are comfortable with usernames and passwords;
  • it is very simple; and
  • it requires no special hardware or software on the client system.

• Less desirable features include:
  • browser password managers can save usernames and passwords on a person's computer;
  • people often mismanage passwords; and
  • username and password systems can be subject to simple brute force attacks or simple guessing.

The username/password scheme relies on randomness of both username and password to make it difficult to guess the correct combination of characters to authenticate as a specific individual. This randomness is usually measured as entropy. Currently, 128 bits of entropy is considered 'cryptographically adequate' for securing information [(Ref: Arjen K. Lenstra and Eric R. Verheul. Selecting Cryptograpic Key Sizes. J Cryptology, Aug 2001 [p 37, 217])] .

Most common username password systems use a derivation of an individual's name as the username. The algorithm for generating usernames from names is generally trivial and provides at most a few bits of entropy. This leaves the password as the only significant test for authentication. The question is "how good is that test"?

There are approximately one and a half million English words. This gives about 19 bits of entropy in the entire language, using words 8 characters or less will have probably no more than 15 bits of entropy.

A random 8-character string (letters only, single case) has about 40 bits of entropy. A random 8-character string of mixed case, numbers and special characters will provide at most 56 bits of entropy.

Only if you have a completely random username and password, each with 9 characters, will you come close to having 128 bits of entropy. Username and password requirements like these are unlikely to survive 'sociability testing' in ordinary user groups. For example: reducing the opportunity for individuals to guess another person password or break the encryption code based on knowledge of that person.

The use of lower quality passwords can be acceptable in authentication systems that incorporate features to prevent brute force attacks.

By allowing only a small number of failed login attempts, even short, low entropy passwords are difficult to guess and may provide suitable authentication assurance.

One time password schemes

The term "One time password" refers to a number of systems that use a system of changing passwords at every transaction, to prevent passwords from being stolen. The most common of these systems uses a password-generating device (a token), which displays a string of letters or numbers that change frequently. The system, which is actually a variation of Secret Type II, uses a secret mathematically combined with the current time to generate the current password. The password-generating token typically resembles a key fob, but can also be implemented in software to run on a computer or handheld PDA.

Writing down passwords

One practice that is broadly discouraged is writing down passwords. However the idea deserves more consideration than it is generally given.

The reason the practice is discouraged is because of the threat that the written passwords will be discovered by a malicious person who will then be able to falsely authenticate himself or herself as the owner of the password.

This is a threat, but it ignores the fact that almost all adults are adept at managing pieces of paper in a secure manner. Most people have spent their life knowing how to store valuable paper (currency) in a secure manner (in their purse or wallet).

If users can be taught to treat a written password in the same way they would treat a $100 note, the risk of losing passwords in this manner would probably be reduced to an acceptable level.

People can also easily learn to write passwords in a secure manner inside, for instance, a diary full of people addresses. A relatively high quality eight character password such as "nh4senZ" could be written as a name and address like:

John Smith

14 Albatross Grove

Wellington, NZ

In a similar fashion, existing names in a diary could be used to generate high quality passwords that could be easily referenced by a user. These methods all have a very low risk of being compromised.

Username / Password Policy

The Government Communications Security Bureau (GCSB) offers guidance in their publication "New Zealand Security of Information Technology Publication 204 - Authentication Services And Mechanisms".

This publication contains detailed information on password formats, including lengths and acceptable characters.

User education related to passwords

In any username / password authentication system, the security and integrity of the system relies on the actions of the user. For this reason it is important to establish well-defined and promoted user education programs. These should include educating the user about the following points:

• Don't use easy-to-guess passwords or the same password for multiple accounts.
• Create passwords that combine alpha, numeric and special characters (such as *) — which makes them harder to guess or crack — and change them frequently.
• Do not save passwords on your system, where they can be copied. Instead, key them in every time you log in.
• Passwords should not be shared with any other person. Persons known to the user are the most likely to commit identity fraud.
• If you have to record your password somewhere, ensure it is stored in a secure place and following the guidelines in the previous section 'Writing down passwords'.
• Never give out your password to any party that has initiated a call or email to you. For example, fraudulent emails or phone calls from persons claiming to be from your bank and asking for your PIN number.
• Periodically check your account information and check when the account was last accessed. Investigate any transactions that appear suspicious or unfamiliar.
• If you suspect someone has compromised your password, contact the agency as soon as possible. This will allow for use of your account to be suspended until the suspicion is confirmed.
• If possible, install virus protection software on any computer that you use to enter your password or access your account.
• Before you conducting any transaction online, ensure you understand what privacy and security protection the vendor has put in place. This includes encryption of passwords across public networks (the Internet) and whether or not the other party is retaining your password.
• Ensure users terminate any active sessions when they are finished, or require them to use an appropriate security mechanism, for example a password protected screensaver.

Digital Certificates

The use of Digital Certificates and Public Key Infrastructure [PKI] are examples of a Secret Type II authentication. Public Key cryptography employs the mathematical relationship between two very large prime numbers to provide a mechanism where one number transforms a block of data (a secret) in such a way that the other number must be used to transform it back into its original form. The first number, called the private key, is kept secret by its owner. The second number, the public key, can be freely distributed to anyone you wish to share secrets with.

PKI refers to the use of public and private keys, together with infrastructure to create, verify and revoke keys in a distributed environment. This may include a 3rd party service provider of a registration process and agreed contractual service performance requirements.

Some PKI implementations also use a physical container for the private key such as a Smart Card, a flash memory device or devices that communicate using Radio Frequency (RF) or Infra Red (IR). These containers typically provide protection for the private keys stored inside by requiring a password or PIN to access the keys. Smart Cards protect the key further by making it unreadable; it can only be used to perform cryptographic operations on the card itself.

A digital certificate comprises the public key, information identifying the holder of corresponding private key, all of which is digitally signed by a trusted certificate issuer called a Certification Authority [CA], for example Verisign or Thawte.

The private key can also be stored on a person's computer, typically using encryption based on a password to reduce the risk of theft.

A private key approach provides secure authentication (and other cryptographic functions) by virtue of having a large secret, typically 1024 bits in today's applications. Guessing this secret using brute force systems is consider impractical using commercially available computers.

Digital Certificates and the use of private and public keys are well supported by common browsers, web servers, application servers and LDAP servers.

However, a private key approach is not without faults. In particular, the task of managing a large number of private and public keys is time consuming and expensive. The infrastructure required to securely create, distribute and manage keys for individuals (and computers) is particularly expensive to establish and operate. Strict procedural enforcement, physical security and detailed auditing are required.

There is another very large problem related to the management of private keys. Unless the private key is stored in a physical container that provides strong security, such as a Smart Card, it can be subject to theft. Even if the private key is encrypted using a password, it is susceptible to relatively simple brute force dictionary attacks. Even worse, it is easy (and tempting) for a user to store a private key on their computer without protecting it with a password. It would be relatively simple for another person to walk up to their computer and authenticate themselves using this type of unprotected Key.

Using secure private key containers like a smart card is, an expensive proposition. Each user would require a smart card (cost range from approximately $10-$30) and would also need a device attached to their computer to read the card. Costs of smart card reader start at approximately $50. The cost of such an implementation across the general public would be significant.

Many users also have a variety of conceptual problems when attempting to use a certificate approach to authentication. These problems include the failure to understand the difference between their login password and the password to access their private key, and confusion resulting from having multiple private keys installed on their computer.

So when should Digital Certificates be used or avoided?

Avoid Digital Certificates if:

• your users may not be sophisticated in their understanding of computers, or
• you have a group of users without a support infrastructure, or
• if you support a very large group of users.

Consider Digital Certificates if:

• you have a requirement for strong authentication (where you are protecting valuable resources); or
• your users are authenticating from computers that are configuration managed; or
• you already have a key management and help desk infrastructure

Multi-Factor Authentication

When authentication is used to protect more valuable resources, a single authentication technique may not be sufficient. In these cases it is common to use two-factor authentication. Most two-factor authentication schemes employ two different techniques, one of them usually Secret Type I.

When considering multi-factor authentication and increased security, selecting a method from each of the categories to form your multiple factors is recommended. For example, combining the selection of a password (something you know) and notification via cell phone (something you have).

Several products support the use of three or more factors for circumstances where the need for very high quality authentication is required.

Multi-factor authentication may also allow agencies to provide a single strength or method of authentication for the majority of their Clients. When a minority of the overall user group require more sensitive or valuable transactions, these Clients are re-authenticated using a stronger authentication method. This would allow agencies to provide simpler and cheaper authentication methods to the majority of their Clients and to provide more complicated, and possibly more expensive, methods only as and when required.

Supporting Infrastructure

As important to the actual authentication technique is the supporting infrastructure that facilitates the registration and storage of authenticating information and the actual authentication exchanges.

Directories

The most common way to store authentication information today is in a directory. Directories using the Lightweight Directory Access Protocol [LDAP] are the most common type of directories and provide fast, hierarchical retrieval of user authentication information. LDAP directories have fine-grain access control capabilities to protect information. They can also reference information in different directories - aiding integration. Most directory products are highly scalable and support replication allowing high availability solutions.

Directory servers can also act as the actual authenticating agent. Most can directly authenticate an individual using either username/password or digital certificate.

SSL

Secure Sockets Layer, and also Transport Layer Security - (TLS), provides a secure transport mechanism for exchanging authentication information. It protects information in transit using encryption as well as identifying both parties in the communication. Most Web Servers and Directories natively support SSL communications.

Identity Management Systems [IMS]

Many vendors provide solution packages that combine the features of a Directory Server with software (typically web-based application) to facilitate the provisioning of individuals in an authentication system. The principal features of these products are to provide support for self-registration of users (note the lack of EOI), and support for automatically dealing with lost passwords (note lack of evidence).

Identity Management Systems typically need strong supporting processes and possibly customisation to meet the requirements of New Zealand Government agencies.

Note that the security of the Identity Management System needs to be on par with overall security requirements of the resources you are protecting.

Access Control Systems

A system that provides control, to varying degrees of granularity, over the resources that an individual can access is called an Access Control System. There are a number of Access Control products that specifically support web sites and online applications. Most of these products either include an authentication system or depend on an LDAP directory to perform authentication.

Data Formats

Data format is an important consideration in any information system.

Authentication relies upon the establishment of Evidence of Identity and the verification of related identity attributes. The schema for storing and exchanging these attributes require particular consideration given the potential for this data to be used across agency boundaries. In particular, the move towards achieving the goals of the E-government Strategy, includes an increased likelihood of name and address data being relied upon across government agencies.

For this reason, readers are referred to the 'xNAL Guidleines'. xNAL is a structured XML language for representing name and addresses.

The xNAL guidelines were written for the NZ e-Government XML Name and Address Working Group and maintained as part of the e-GIF.

Agencies should also give serious consideration to ensuring that the character set used in their system is appropriate to meet their business needs. For example, the use of Unicode may assist agencies in accurately recording Client name data in particular ethnic scripts, macrons and accents.