Until passwords are extinct, we must manage them. After passwords are extinct, we must manage their replacements.

For those familiar with the Federal Information Security Management Act (FISMA) evaluations, the concept of Authenticator Management should be familiar from the security control IA-5.  As with many security controls, this short designation covers a considerable number of requirements. This series of blog post will review the contents of the control requirements, how they are commonly implemented and how they are assessed, with the overall goal of determining whether improvements are needed to implement and assess the security control properly.

This blog post covers a definition of authenticator and related terms.  Subsequent posts will explain the status of the Federal Government’s Identity and Credential Access Management (ICAM) security program, and unpack the requirements of the FISMA security control IA-5 and its control enhancements.

What are Authenticators?

Authenticators come in the form of passwords (aka PINs) or cryptographic keys.

Authenticator is defined by National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 as “the means used to confirm the identity of a user, processor, or device (e.g., user password or token).”  The closest equivalent term in NIST 800-63-2 (Electronic Authentication Guidance) is the Token Secret (not, unfortunately for consistency, the Token Authenticator) which is a kind of Long Term Authentication Secret. In practice, authenticators come in the form of passwords and keys. 

Biometric Secrets are not Authenticators.

Authenticators are distinct from biometric secrets, which are also long term data that pertain to an individual, but unlike authenticators, biometric secrets are bound to a person’s physical characteristics and are not subject to the same sort of management functions. 

Physical Tokens are not Authenticators, but they can contain Authenticators

The term Token is overloaded in the security world, carrying meaning of a container for keys or other secrets, deriving from the use of the term in the PKCS#11 Cryptographic Token standard.  With the development of Federal Information Processing Standard (FIPS) 140-2, the term Cryptographic Module is now a more precise expression of what PKCS#11 tokens embody.  Whether implemented in hardware or software, a token or cryptographic module is a container that stores and may or may not provide management functions related to authenticators.  For example, FIPS 201 Personal Identity Verification (PIV) cards physical tokens that bind an identity to an authentication key, so the actual authenticator on a PIV card is the PIV authentication key.

Why Manage Authenticators?

Authenticators are encountered at many levels – operating system, database, application, communication protocols – and everywhere they are implemented, there is a potential point of security weakness.  Even if the password function is carefully implemented by product developers, users always have a responsibility on their end to participate in a system that minimizes risks by managing passwords and keys according to best industry standards and practices.

In brief, authenticator management is important because passwords are a terrible source of security risk, especially when they poorly managed.  There are many efforts underway to replace passwords, including the National Strategy for Trusted Identities in Cyberspace, whose spokespeople always include a pitch for the destruction of passwords.  The FIDO (Fast Identity Online) Alliance has made progress in implementing the Universal Second Factor (U2F) and the Universal Authentication Framework (UAF), with version 1.0 specifications of each published on 2014-12-09.  However, until passwords can be eliminated, there are ways to minimize the risks.

For example, according to Krebs on Security’s recent article about the Target breach of 2013, auditors and penetration testers found that Target’s management of passwords had a number of flaws, including weak and default passwords, valid passwords being shared in files on the network, with overall password strength being weak enough that 86% of them could be cracked in a week by the penetration test team.  These practices resulted in Target facing a class action lawsuit from banks whose customers were affected by the breach, so there are very serious consequences to an organization for not following authenticator management practices.

Stay tuned for the next article on the U.S. Federal Government’s Identity and Access Management Security Program.

Contributed by: Scott Shorter