The Ultimate Cheat Sheet on Strong Authentication – Part 2

As promised, here are a few more quick strong-authentication facts on the subject of strong authentication for those new to the topic, or those looking to introduce the topic to the uninitiated. How are one-time passwords generated? What is the difference between an Assurance Level and a FIPS Security Level? And what is OATH authentication?

 How is a one-time password generated?

In OTP authentication, one-time passwords, or OTPs, are generated using four main inputs:

  • A secret token seed, consisting of a randomly-generated string usually 256 bits or 512 bits long
  • A time-synched or event-based parameter, such as a timestamp for time-based OTPs, or a counter for event-based OTPs
  • Other variables, which add entropy
  • A hashing algorithm, which combines the above inputs to produce a single OTP value

OTP = [HASHING ALGORITHM] [TOKEN SEED] [TIME OR EVENT-BASED VALUE] [OTHER VARIABLES]

What is a Level of Assurance?

In terms of authentication, a level of assurance denotes the level of certainty that a user is who they claim to be. Different authentication methods provide different levels of assurance, for example, a static password provides a low level of assurance, whereas two-factor or multi-factor authentication provide a higher level of assurance.

When determining the level of assurance required to secure access to a specific resource, IT and security professionals take into consideration the risk and value of the ‘information asset’ in question—for example, the enterprise VPN vs. an attendance web application. As well, higher privilege accounts, such as those belonging to network administrators or C-level personnel, generally require a higher level of assurance than a standard account (since unauthorized access to these accounts could result in much greater losses or damage).

What is a NIST Assurance Level?

In its Electronic Authentication Guideline, the US National Institute of Standards and Technology, aka NIST, has laid out a system that anyone can use to calibrate the level of assurance provided by a specific authentication method or a combination of methods, represented in ascending order of security from Assurance Level 1 to Assurance Level 4. (For details, see pages 51 thru 55 of.) Here are some examples:

  • Assurance Level 1 – A password or PIN
  • Assurance Level 2 – An OTP, generated by a soft token
  • Assurance Level 3 – A PIN-protected OTP, generated by a soft token
  • Assurance Level 4 – A PIN-protected OTP, generated by a hardware token

Note that Assurance levels 2 and higher require that the cryptographic module be FIPS validated. More on this below.

What is a FIPS Security Level?

Not to be confused with NIST Assurance Levels, the FIPS 140-2 is a series of US Federal Information Processing Standards (FIPS) that rate the security of a cryptographic module, in ascending order of security from Security Level 1 to Security Level 4:

  • FIPS 140-2 Security Level 1 – Applies to the cryptographic module, or software component, of a cryptographic system. An OTP app, for example, can be FIPS 140-2 Level 1 validated when it incorporates FIPS-validated crypto libraries.
  • FIPS 140-2 Security Level 2 – Applies to the physical casing of a cryptographic module (e.g. a token) and requires that it be tamper evident, meaning that visible signs of manipulation appear in the event of physical access in order protect the plaintext encryption keys from manipulation or duplication.
  • FIPS 140-2 Security Level 3 – Stipulates the zeroing (‘self-destruction’) of encryption keys in the event of tampering or physical access to a token.
  • FIPS 140-2 Security Level 4 – Requires complete protection of the encryption keys from extreme physical or environment conditions (e.g. Space, lab settings, etc.), so that even manipulation of such conditions do not reveal the encryption keys.

In the EU and APAC regions, the Evaluation Assurance Levels (EAL) of the Common Criteria  (CC) standard are more widely referenced, comparable to the FIPS 140-2 standard used in the US and Canada.

Cloud use case - Identity Federation
What is Identity Federation?

Identity federation means using an identity from one security domain to access another security domain. An example would be using the identity Jill@abc.org to not only access the abc.org network, but to access 3rd party applications, as well, such as Office 365, Salesforce.com or AWS. When Jill’s enterprise identity is extended to the cloud, or ‘federated,’ she can access all her cloud-applications with her familiar enterprise identity.

Identity federation can help eliminate the help desk overhead and password fatigue that results from having 10 or 20 disparate username-and-password sets for different cloud applications.

Federation is achieved using different protocols, for example Kerberos for on-premises applications, and SAML for cloud-based applications. (For more on SAML-based federation, watch this webinar on Securing access with SafeNet Authentication Service.)

What is OATH Authentication?

OATH Authentication is an open standard for implementing strong authentication. Produced by an industry-wide collaboration of security vendors, the OATH architecture can be used by IT and security professionals as a template for integrating strong authentication into their organization’s current infrastructure.  OATH’s open standards create more freedom for enterprises by preventing ‘vendor lock-in’ and thereby offering a broader choice of vendors, and enables using an OATH-based token across different vendors’ platforms. Token seeds can be exported from one OATH platform, and imported into another OATH platform.

Proprietary vs. Open Authentication Standards

Authentication technology, like other technologies, may be either open source or proprietary. SAML 2.0, OATH, and OpenID Connect are all open standards that are available to the public and developers free of charge. WS Federation Services, conversely, is a proprietary identity federation protocol created by Microsoft, who also supports SAML.  Similarly encryption algorithms used in 2FA may be either be proprietary or open source, with examples of the latter being TOTP and HOTP (both OATH 2FA protocols). Proprietary methods are often more lucrative for vendors, whereas open standards that have undergone peer reviews and public scrutiny tend to enjoy greater industry-wide support.

Discover more about strong authentication in part 1 of the series and read A Security Survey of Strong Authentication Technologies – Whitepaper.

 

Leave a Reply

Your email address will not be published. Required fields are marked *