Authentication and government contracts: the password requirements of NIST and DFARS

Standards and Regulations

Authentication and government contracts: the password requirements of NIST and DFARS

Read more
Mar 12, 2021

Government contracts can be very attractive for organizations of any size. A testament to the fact is the fierce competition between large tech companies to win the bid for the Department of Defense’s (DoD) JEDI project, worth over $10 billion.

But public sector contracts have their own set of caveats and sensibilities, and not taking them into consideration can land an organization in hot water. Every organization that becomes engaged in work with a government agency must conform to a set of security standards and regulations.

Key among them are rules set by the National Institute of Science and Technology (NIST), a body that develops information processing standards for all federal agencies must follow. NIST sets standards for different areas of information processing, including identification, authentication, information storage and processing, and much more.

Organizations that want to work with the DoD must also comply with the Defense Federal Acquisition Regulation Supplement (DFARS), a set of standards that apply to civilian and defense agencies across the US, as well as any organization that handles this data on their behalf. With increasing oversight and enforcement, DFARS compliance is more important than ever for companies in the DoD supply chain.

Organizations that fail to comply with these rules, or suffer security incidents that result from poor compliance, can get hit with back-breaking fines and class-action lawsuits that can possibly drive them out of business.

Finding the balance between convenience and security

For many years, security experts have been telling users to use long, complex passwords composed of lower- and upper-case letters, digits, and symbols to avoid falling victim to brute-force attacks. Moreover, users are required to choose unique passwords for each account and change those passwords every few months.

Here’s an example of a password that is long and complex:


This password surely conforms to all those security requirements, and even the craftiest hacker armed with the most efficient password-cracking software won’t be able to guess it in any reasonable amount of time. In an ideal world, all users would choose such passwords for their accounts.

But in reality, such things almost never happen. Complex passwords are hard to remember. And imagine having to remember one such password for each of your dozens of online accounts and generating a new one every few months. The cognitive load is so great that most users don’t bother and end up finding workarounds such as storing their passwords in plain text documents on computers and reusing them across different accounts.

It was for these very reasons that NIST relaxed some of its rules surrounding password structure. Complexity and periodic password changes were removed. Instead, passwords should be between 8 and 64 characters and changes enforced if there is a suspected breach. Organizations must also check new passwords against available compromised password lists such as haveibeenpwned before accepting them.

The NIST’s guidelines show that password complexity has already reached its limits. Our computers are becoming faster and more powerful every year, putting more effective weapons in the hands of hackers. But our brains have pretty much the same processing power they’ve had for the past 100,000 years, which means we can’t keep up with the growing complexity requirements of secure passwords.

Password storage and management is a nightmare

Once organizations take care of password complexity problems, they must deal with a greater problem: where and how to store the passwords. Organizations must make sure that the passwords are hashed before being stored on their servers. Plaintext passwords are even worst than simple passwords because a data breach will give hackers access to all the accounts the organization handles.

Today, most organizations store hashed passwords. But again, the past few years have proven that hashing alone is not enough. Organizations must also control employee access to those passwords and make sure unauthorized personnel can’t extract user account passwords for their own purposes. As several security incidents have shown, mishandling of user credentials happens even at companies with firm credential handling policies. An example is Facebook, which according to security reporter Brian Krebs had mistakenly given access to 200-600 million user passwords to its employees.

Another challenge organizations face is detecting and blocking malicious attempts to access accounts. When the only thing protecting users’ sensitive data is a password, hackers can break into the targeted account by staging brute force or credential stuffing attacks. Organizations must implement safeguards that detect and block multiple failed attempts to access an account. When they don’t, things can go very bad. An example is the Ring security camera, which failed to block malicious access to user accounts and resulted in sensitive video feeds falling into the wrong hands.

When you’re running a commercial business, such shortcomings can result in financial and reputational loss. When you’re a subcontractor of DoD or another government agency, such shortcomings can cause a lot more trouble.

The mediocrity of multifactor authentication

Clearly, passwords alone—and uncomplicated ones at that—will not be enough to secure user identities. That’s why many organizations are implementing multifactor authentication (MFA). In a nutshell, MFA verifies users’ identities by requiring them to provide something they know (e.g. password), and something they have (e.g., mobile app, security key) or something they are (e.g., fingerprint scanner, facial recognition).

DFARS certifies certain types of MFA, including certificates that are securely stored on an endpoint (e.g., using the keychain storage, TPM, or TEE). The key must also be strongly protected against unauthorized disclosure and be only accessible to the relevant software components. Finally, organizations must make sure they prevent the propagation of keys across multiple devices, or in case that it is inevitable, they should minimize the need for doing so.

MFA adoption has hit its own hurdles. Many users already have an issue with entering passwords every time they want to access their accounts. The added friction of entering another one-time passcode (OTP) or producing a physical key in the login process often puts them off, pushing them to disable it altogether if they have the option.

The passwordless solution

The ultimate goal of every organization is to maximize security and ease-of-use. But the problem with classical authentication paradigms is that they often create a conflict between convenience and security. This leaves organizations torn between compliance and user satisfaction.

A solution that provides the best of both worlds and enables organizations to remain compliant with the latest (and future) NIST guidelines while also giving users the optimal experience is passwordless authentication.

For instance, Secret Double Octopus’ authentication solution replaces passwords with biometric authentication that is available on most devices today. It also incorporates transparent multifactor authentication into one authenticator app. As far as users are concerned, they access their accounts with a one-tap authentication. But under the hood, the Octopus Authenticator uses a strong proprietary mechanism that is resilient against various types of attacks such as credential stuffing and man-in-the-middle attacks.

Government contracts are a very tricky landscape. You better come prepared.

More Things That Might Interest You

Standards and Regulations

What is SAML and how is it being used?

Read more
Sep 3, 2020

Standards and Regulations

Your Complete Guide to FIDO, FIDO2 and WebAuthn

Read more
Jun 30, 2020

Standards and Regulations

Authentication Federation VS Single Sign-On

Read more
Jan 3, 2020