Pesky Passwords?

November 1, 2018
R.D. McDowall

Spectroscopy

Volume 33, Issue 11
Page Number: 20–23

The password paradox states that simple passwords are simple to remember but easy to break, but complex passwords that are difficult to hack are also difficult to remember. Is there a better way?

You know the situation. You go on holiday, have a great time, and the first day back in the laboratory you tell everyone about it, and then reality dawns. You must do some analysis. You go to your spectrometer system or the LIMS, try to log on and your mind goes blank..... What's my password? You have forgotten it! At this point it depends if your system is networked or not, but you either have to contact the IT help desk or an administrator, get your grovel pads out and beg for a password reset.

What will happen now is that you will get a one-time default password, that when you log on to the system, you will be forced to change it. Now comes your big test: navigating the minefield that is your organization's rules for password complexity. Your super holiday memories are now receding into the mists of time at warp factor nine.

Current Password Rules

Now we come face to face with the password paradox: easy to remember but easy to hack, and so on. To meet the rules, your new password must:

• be at least 8 characters long
• have at least three or all of the following:

     - one upper case character
     - one lower case character
     - one number character
     - one special character.

And you have to remember it!

Here goes: take the word "consultant" and convert it to meet your password rules into c0n5Ultan! There you go; it just rolls off your fingers as you type on the keyboard. The problem is remembering it. Here is where your pen hovers over an easily available piece of paper, ready to write it down and break at least three of your organization's additional rules on passwords.

Then, just to make your descent into password purgatory even more interesting, every 30, 60, or 90 days you must replace it, and you can't reuse an old one.

Don't Do This in the Lab!

Passwords are a fact of life. Dumb and stupid passwords are also a fact of life. I was going to show you the most popular passwords from the hacked Ashely Madison web site as an example of poor password selection. However, this is a scientific magazine, and, as the editors would have redacted most of them, a more boring section of the top 20 stupid passwords of 2017 is displayed in Table I. You can imagine the cerebral effort that the owners of these passwords used in devising them.

 

Quo Vadis Passwords?

The biggest issue with complex passwords is remembering them, so this is why they are written down by some users. As an auditor, I take great delight in turning over keyboards in the laboratory to see if there are any notes underneath with passwords written on them. Although, in some laboratories, my job is made immeasurably easier, as shown in Figure 1. Even better was a typed note on the keyboard of one instrument: Operator Password = 1111. The philosophical question that arises is, What idiots are employed here that need a written reminder for such a password?


Figure 1: How not to set up user accounts (2) (published with permission from the RSC).

Let us question the need for complex passwords and changing them regularly. Are both requirements absolutely essential? It appears that there is a whole IT security industry built on the premise that we need strong passwords that are changed at regular intervals. Operating systems, and many general as well as laboratory applications, have functions to ensure that these requirements are enforced rigorously.

Getting Around Password Complexity

We have password complexity rules, which are a pain to comply with. However, intrepid users have simple ways of meeting the password policies. We'll take an example from Table I: password.

  • We need an upper-case character = Password

  • We need a number = Password1

  • We need a special character = Password1!

  • We need to age the password = Password2!, Password3!, and so on.

Simple compliance, but easily broken. Hence the need for a directory of unacceptable passwords.

Back in the Laboratory

Consider the problem with passwords from an analyst's perspective. You want to do some spectroscopy, and you must log on to an instrument to do this, but verifying who you are is an activity that stands between you and the spectrometer. Logging on is a pain with complex passwords; essential for ensuring data integrity and data security, but still a pain. Implementation of a policy for complex passwords may lead to compromised security, as users are more likely to write down their complex passwords, or there is an increased number of calls to the IT Help Desk to reset locked accounts. The issue is compounded if a user needs to access multiple systems each with a different password; oh, joy. Hence the rise for networked applications of single sign-on, and only a single password to remember. Unfortunately, even with a single complex password, it is not easy to remember, and hence the unofficial workaround of writing it down.

However, approaches to passwords and their construction have changed. Enter stage left the NIST Information Technology Laboratory.

NIST Special Publications 800 Series

NIST is the National Institute of Standards and Technology, a U.S. government science facility that produces standards, reference materials and lots more besides (see www.nist.gov for more details). One of the divisions of NIST is the Information Technology Laboratory that is responsible for developing IT and cybersecurity standards for the U.S. government and its agencies. One of their outputs is via a series of NIST special publications 800 series (https://csrc.nist.gov/publications/sp).

In this column, I want to focus on a suite of standards under the esoteric title of n SP-800 63 Digital Identity Guidelines. This consists of the following documents:

  • SP 800-63-3, Digital Identity Guidelines, provides an overview of general identity frameworks, guidance regarding use of authenticators, credentials, and assertions together in a digital system, and a risk-based process of selecting assurance levels (3).

  • SP 800-63A, Enrollment and Identity Proofing; the process to verify users are who they claim to be (4).

  • SP 800-63B, Authentication and Lifecycle Management; an authenticator is something a user has and controls (such as a password) that is used to authenticate the subject's identity (5).

  • SP 800-63C, Federation and Assertions; this is verification of a person's identity by a trusted third party, who can then provide this information to other parties. As such, it is outside the scope of our password discussion (6).

You may be wondering what all this has to do with passwords. As you delve into the detail, you find some gems that help the password debate are contained in SP 800-63B (5).

How Secure is Your Computer?

SP 800-63B (5) presents three levels of Authenticator Assurance Level (AAL 1, 2 or 3). The higher the AAL, the better the capabilities and the greater the resources required to hack a computer. Therefore, risk of unauthorized access is reduced compared with a lower AAL or lesser effective protection.

  • Authenticator Assurance Level 1 (AAL1) provides confidence that user are who they claim to be by single-factor authentication (password) in combination with a valid user identity to access a computerized system. Key to success is that users do not disclose their passwords, and that the passwords are of sufficient strength to deter a hack.

  • Authenticator Assurance Level 2 (AAL2) provides high confidence that users are who they claim to be via two factor authentication. This is typically a known password followed by entering a number that is sent via text or voice to a user's registered phone number.

  • Authenticator Assurance Level 3 (AAL3) provides very high confidence that users are who they claim to be, as they are in possession of a cryptographic key and hardware registered to a user. Authentication at this level is based on proof of possession of a key through a cryptographic protocol.

As you can see, with passwords alone, we are down with the bottom feeders on AAL1. Don't despair, there are other factors to consider, such as physical security of your buildings and laboratories to mitigate the data security risk but not data integrity.

 

Password Guidance from NIST SP 800-63B

What does this NIST publication call a password? A memorized secret authenticator(MSA). Why make something simple, when you can make it complex? Don't worry, I'll refer to MSAs as passwords from now on.

A password is something that is known only to you, and is impractical for a colleague or hacker to guess (with the exceptions presented in Table I). Although the NIST SP 800-63B mentions that service providers can allocate you a secret password, I will only consider passwords that you can make up yourself.

This NIST Guide notes that:

  • Passwords should be at least 8 characters long.

  • There will be a list of disallowed passwords (such as those in Table I), so if you select one on the list you will be required to select another password.

  • No other criteria are required (5).

Whoa! What happened to the complexity criteria that we listed earlier?

In Section 10.2.1, there are some usability criteria for passwords that are summarized in Table II. Some of these comments will cause apoplexy in many IT/IS departments, due to their being no complexity and no enforced password aging. You can almost hear the sacrifice of sacred cows in the background.

Appendix A of NIST SP 800-63B (5) is devoted to a discourse on passwords, and it notes that users are frustrated with having to remember complex passwords; this is compounded by our brain's limited ability to remember them. Hence the selection of simple, easy-to-guess passwords as shown in Table I. Of note, there are the following sentences:

  • Analyses of hacked password databases has shown that the benefit of policies for complex passwords is not as significant as initially thought, but there is severe impact on usability (5).

  • Users should be encouraged to make their passwords as lengthy as they want, within reason (5).

The old criterion that password complexity is essential for computer security is not proven, and the sole requirement for computer security is password length so that passwords can be easily memorized. Allied to this is the need to avoid the use of commonly used passwords. As NIST SP800-63B notes apart from length "no additional complexity requirements are imposed" (5).

Each time a character is added to a password, the difficulty to crack it increases exponentially. For example, an 8-character password has 958 combinations (95 being the number of keys) and a 10-character password has 9510 combinations. However, this only applies on brute force attacks. Most of our laboratory systems in the laboratory should have a limit on the number of attempts before an account is locked.

The Good News or the Bad News?

The good news is that password complexity and aging are not essential elements for computer security as shown in NIST SP800-63B. Will corporate password policies change? The bad news is, probably not.

References

(1) K. Korosec, "The 25 Most Common Passwords of 2017 Include 'Star Wars'" (2017). http://fortune.com/2017/12/19/the-25-most-used-hackable-passwords-2017-star-wars-freedom/.

(2) R.D. McDowall, Validation of Chromatography Data Systems: Ensuring Data Integrity, Meeting Business and Regulatory Requirements (Cambridge: Royal Society of Chemistry, Cambridge, UK, 2nd Ed., 2017).

(3) P.A. Grassi, M.E. Garcia, and J.L. Fenton, NIST Special Publication 800-63-3 Digital Identity Guidelines (National Institute of Science and Technology, Gaithersburg, Maryland, 2017).

(4) P.A. Grassi and J.L. Fenton, NIST Special Publication 800-63A: Digital Identity Guidelines Enrollment and Identity Proofing Requirements (National Institute of Science and Technology, Gaithersburg, Maryland, 2017).

(5) P.A.Grassi, J.L. Fenton, E.M. Newton, R.A. Perlner, A.R. Regenscheid, W.E. Burr, and J.P. Richer, NIST Special Publication 800-63B: Digital Identity Guidelines Authentication and Lifecycle Management (National Institute of Science and Technology, Gaithersburg, Maryland, 2017).

(6) P.A.Grassi, J.P. Richer, S.K. Squire, J.L. Fenton, and E.M. Nadeau, NIST Special Publication 800-63C: Digital Identity Guidelines Federation and Assertions (National Institute of Science and Technology, Gaithersburg, Maryland, 2017).

R.D. McDowall is the Director of RD McDowall Limited and the editor of the "Questions of Quality" column for LCGC Europe, Spectroscopy's sister magazine. Direct correspondence to: SpectroscopyEdit@ubm.com