• Revised NIST cybersecurity framework mandates password policy.
• Rules and guidance updated.
• What you need to know, and what everyone SHOULD do.

The US National Institute of Standards and Technology (NIST) has published a revision to its guidelines on authentication for organisations that interact with government information systems. The stipulations are designed to ensure that organisations like government contractors use strong practices for authentication, passwords, and security.

While the requirements of the NIST cybersecurity framework are there to be adhered to by a very specific subset of organisations, its contents form a handy guide tor any business or organisation that wants to ensure its practices are robust. To that end, it can be used when implementing any facility present online that needs to be secure. In very simple terms, putting the guidelines in place wil go a long way to removing any company from the list of easier targets for bad actors.

The document covers many aspects of security and authentication and may be an informative guide for all organisations. But given that the simplest data breaches are caused by humans and their poor password practices, taking on board the contents of section 3.1.1. Passwords and, more importantly, acting on it, will be the wisest decision you make this year.

Requirements for passwords

The document makes a clear distinction between ‘shall’ and ‘should’, boldfacing and capitalising the use of both. In section 3.1.1.2. Password Verifiers, we find the following:

[Verifiers and CSPs]^* SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.

There’s no reason why any password should be short. Setting a minimum of eight characters should probably be avoided as a matter of course, in favour of the at-least 16 characters advised. Requirements for long passwords dissuade users from using simple passwords that are often easily guessed, or exist in one of the many available lists of common passwords.

Attackers attempting brute-force entry into a system will, as a matter of course, use automated scripts to fire password attempts from the lists at a site or app.

[…] SHOULD permit a maximum password length of at least 64 characters.

Limits on password length derive from a time when passwords were stored in databases with no or minimal encryption. Limits on password length saved disk space. Today, stored passwords should be hashed (encrypted and appearing as set number of characters) so a 200 character password will take as much room as a 29 character password.

There is an argument that a very basic denial-of-service attack could inject passwords of megabyte proportions into a system repeatedly, so tying up the hashing algorithms. Some limit on password length may be appropriate, therefore, but it can easily be in the hundreds of characters without compromising system performance.

[…] SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.

The strictures that we as users sometimes see (“Passwords should not contain spaces or special characters like SPACE,*.+^’ or $”) should be irrelevant if the authentication method is secure. If a service states such characters can’t be used, its owners’ systems may be insecure and should be avoided.

[…] SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.

Unicode characters are present everywhere, and are the accents and basic symbols we see in everyday use. Any authentication system old enough to object to their presence needs replacing. Unicode was pretty much standard in computing by the mid-1990s.

[…] SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

The addition of rules that require the certain presence of uppercase, lowercase, numerics and punctuation actually do nothing to improve password strength. In fact, as this article from Troy Hunt demonstrates, doing so actually encourages users to use insecure passwords. ‘Password1!’ may fit the criteria, but it will be broken in less time than it takes to type.

[…] SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Regular, enforced password changes are another piece of historical advice that’s been shown not to be particularly effective, as it encourages users to recycle a set of passwords they know well, perhaps adding a digit to the previous version: ‘Password12!’ is new, so passes the simple algorithmic test of ‘is it different?’ but is still intrinsically weak and crackable.

In the event of a security breach, passwords should be changed immediately, and the need to change password should be enforced on all users.

[…] SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.

A hint, available in plain text, available to anyone inputting the wrong password. Secure? The NIST cybersecurity framework says not.

[…] SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.

Anyone setting up Windows 10 without a Microsoft account will know these prompts well. If the respondent has set these with correct answers, typical answers are, like common passwords, available to download as text files that scripts can parse. Your mother’s maiden name is a matter of public record, too.

Verifiers SHALL verify the entire submitted password (i.e., not truncate it).

Security researchers have found that some gateways simply ignore any characters entered after a certain number. A password with 128 characters in it can be, therefore, as insecure as one with 12 if a programmer made the mad decision to truncate the input.

^* anyone verifying a password, and credential service providers – “A trusted entity that issues or registers subscriber authenticators and issues electronic credentials to subscribers.“

How to ensure relative safety

Teaching people the best ways to choose their own passwords doesn’t work. Despite the best efforts of generations of cybersecurity trainers, there are enough people that will continue to use passwords that are simple. And in an organisation of 1,000 people, 60 will use some variation on the word ‘password.’

More often than not, it only takes a few (or one) accounts to be compromised for a company to be breached, if not immediately then by some other means made easier: impersonating a colleague it communications, for example. Your organisation may not have to adhere to the NIST cybersecurity framework to function, but without following its precepts, it may well be forced to cease trading. There are several practical ways to protect any organisation, however that are better than leaving people to their own devices to choose passwords.

• Enforce multi-factor authentication everywhere. This can be a verification token app, a hardware device, or something more basic like a smart card. Avoid SMS multifactor authentication – it’s an old and insecure medium.
• Make sure that everyone uses a password manager. A phone app unlocked with a fingerprint or facial recognition will create, remember and regurgitate a practically infinite number of strong passwords that are easily retrieved in apps, on the web, even in the command line your IT team loves.

Deploying both measures will cost the company around the equivalent of a couple of cups of coffee a year for each employee. If that’s a price too high for the business, we suggest cutting out the middleman and simply publishing all the organisation’s sensitive information online.