Authentication
Authentication is about proving the identity of someone or something, or verifying that someone or something is in fact truly who they say they are. Why do I say “someone or something”? Well, someone refers to a person, and something refers to anything else that needs to be authenticated. Keep in mind that systems, devices, tools, applications, and so on need to be authenticated. If you are only focused on people, you are leaving your organization vulnerable to attack.
There are a multitude of factors that people, systems, devices, applications, and tools can use to authenticate. Table 3-2 explores these factors and provides examples.
Table 3-2 Authentication Factors
Factor |
Description |
Examples |
|---|---|---|
Something you know |
This is authentication based on knowledge. |
A username, a password, a personal identification number (PIN) you have memorized, a passphrase you have memorized, CAPTCHA test, personal verification questions |
Something you have |
This is authentication based on possession. |
A security token that can provide you with a random PIN A random PIN, passphrase, or notification from your smartphone that you can accept or reject A swipe card, tap card, or passkey |
Something you are |
This is authentication based on unique aspects of yourself and relies on biometrics. |
Your fingerprint, your facial geometry, your retina, your palm print |
Somewhere you are |
This is authentication based on location. |
You are allowed or denied based on your connection to the corporate Wi-Fi versus coffee shop Wi-Fi versus airport Wi-Fi versus home Wi-Fi. You are allowed or denied based on your connection in the United States versus Canada versus any other country. |
Something you do |
This is authentication based on habits and characteristics. |
The way you walk, the way you write, the way you talk, the path you take to work, the places you eat lunch, the sports you play and when |
Time |
This is authentication based on the time of day and/or day of the week. |
You are allowed on the Internet between 9 a.m. and 5 p.m. and are not allowed on the Internet between 5 p.m. and 9 a.m. You are allowed to connect to the VPN Monday through Friday, 7 a.m. to 9 p.m. local time |
Multifactor Authentication (MFA)
Using a single factor of authentication is no longer advisable. For example, relying on a username and password (a single factor: something you know) will not protect you as it once did. Cybercriminals have developed very creative ways to figure out your username and password (such as via a convincing phishing email), and once they know them, they will be able to access anything you can access with them. The same thing is true with PINs or passphrases that you have created and memorized. Once a cybercriminal has that information, they will have access to systems and data you don’t want them to have access to.
One of the best ways to protect yourself today is with multifactor authentication (MFA). MFA involves using two or more of the factors mentioned previously, in combination, to successfully authenticate (for example, combining something you know with something you have or combining something you have with something you are or combining something you have with somewhere you are). As of this writing, MFA is becoming closer to being the norm for every application and service that exists.
Now please note that MFA does not protect you from becoming the victim of a phishing attack that is designed to steal your credentials—or any other type of attack for that matter. It does, however, help prevent the cybercriminal from gaining access to your systems and data based only on the credentials they stole in the phishing attack. How so? Well, even though they may have stolen your username and password, they do not have the second factor that is needed to successfully authenticate to the systems and access the data. For example, let’s say your first factor is a username and password. Regardless of how strong the password is, it could be stolen/captured during a phishing attack or a data breach targeting your authentication database. If you have a second factor that is required, like a one-time PIN generated by an application installed on your cell phone that is valid for only 30 seconds, the cybercriminal will not be able to access your systems and data because they do not have your cell phone and can’t get the one-time PIN—and they also can’t guess it or brute force it because it changes every 30 seconds.
Table 3-3 provides examples of MFA.
Table 3-3 Examples of MFA
Factor 1 |
Factor 2 |
Description |
|---|---|---|
Your bank card |
A memorized PIN |
Your bank card is one factor (something you have), and the PIN is the other factor (something you know). |
A swipe card |
A retinal scan |
The swipe card is one factor (something you have), and the retinal scan is the other factor (something you are). |
A username and a password |
A notification sent to your phone that asks you to click yes or no |
The username/password is one factor (something you know), and your phone with the notification is the other factor (something you have). |
A fingerprint scan |
A PIN |
The fingerprint scan is one factor (something you are), and the PIN is the other factor (something you know). |
A username and a password |
Your location |
Your username/password is one factor (something you know), and your location is the other factor (somewhere you are). |
Please be aware that true multifactor authentication requires two or more different factors, as shown in Table 3-3. So, having a username/password and a memorized PIN is not MFA as they are both something you know—and so count as only one factor. A retinal scan and a fingerprint scan are not MFA as they are also the same factor (something you are). Having your phone that generates a PIN that you enter and then an app on your phone that gives you a one-time password is not MFA as these are, again, the same factor (something you have). These are all examples of two-step authentication because two steps are needed for authentication, but only a single factor is being used. What I want you to realize from this is that if you implement MFA poorly, you might not be as protected as you think you are, and you would do better with other combinations. For example, what would you consider to be stronger?
Option 1. A username/password and a six-digit one-time PIN generated at the time it is needed
Or
Option 2. A USB authentication key that needs to be entered into the system and then a notification displayed on your phone that needs to be accepted or rejected
So, option 1 is an example of MFA as there are two different factors in use, and option 2 is an example of two-step authentication because the same factor is used twice. In this case, it is clear that it would be much harder for the cybercriminal to access your system with two-step authentication (the USB key and your phone) as they would need physical access to both those devices and the system they are accessing. Although option 1 is a great option and highly recommended, you can see that strength comes from the combinations and not necessarily from just different factors being used. So, for the CCST Cybersecurity exam, be clear about the difference between MFA and two-step authentication in case you have to pick them out of a lineup.
Passwords and Password Policies
The most common way to authenticate today is with a username and password. Regardless of whether they are used as the only factor or as part of MFA or as part of two-step authentication, usernames and passwords are not going away anytime soon. Therefore, it is important to ensure that passwords meet certain requirements so that they are less apt to be easily guessed or determined using brute-force techniques and then reused by cybercriminals. In addition, they should be stored securely (hashed) in a database so that if the database is compromised, the likelihood of a cybercriminal being able to use any of the passwords in the database is significantly reduced.
So, what should a password be? It should be:
Something that is not guessable
Something that can’t be brute forced
Something that the user can remember without having to write it down
Something that can be used for a long period of time
We used to encourage complexity by forcing users to include lowercase letters, uppercase letters, a digit, and special characters, but users would do the minimum to meet the requirements instead of creating complex passwords. For example, the password “password” would simply become “Password1!” which is not complex at all. We wanted them to use something like “Yt56R34w” but got “Password1!” instead. So, complexity requirements really haven’t worked out as they were intended to and still result in passwords being guessable, brute forced, and written down.
Now we encourage length. The longer a password is, the harder it is to guess, and the harder it is to brute force. Users can now use passphrases or sentences for their passwords, which they can remember with ease without writing them down. For example, the password “We_Love_Oranges_And_Orange_Marmalade” is not easy to guess, it is impossible to brute force, and the user will not have to write it down. In addition, it will not have to be changed for a long time.
So, what would be a good password policy today? A good password policy would
Encourage length (12 characters minimum with no maximum).
Encourage the use of passphrases or sentences (something easy to remember but really long).
Force the use of an uppercase letter, a special character, and a number and allow the rest to be all lowercase.
Increase the number of days between password changes to a year or more.
Now a user can create a password such as “B3ing_A_CCST_Cybersecurity_Is_Awesome!” which would meet all the requirements of the password policy and more while being impossible to guess or brute forced, and the user will not have to write it down. If they don’t want to use the special character _, then it would still be acceptable to use “B3ingACCSTCybersecurityIsAwesome!”. You could even omit the special character ! or the number, and this would still be a very safe password.
In addition, because of the length requirement, a user could use their password for a longer period of time. Instead of forcing users to change their passwords every 30 to 90 days, you could let them change it every year or even every few years. According to the website How Secure Is My Password, at https://www.security.org/how-secure-is-my-password/, it would take a computer about 1 hundred tredecillion years to crack (brute force) the password “B3ingACCSTCybersecurityIsAwesome!”. So using this password for a few years without changing it should be fine.
When it comes to storing passwords in a database, it is imperative that you use hashing and salting. Hashing is done so that the password is stored as a hash instead of plaintext. This way, if the database is ever exfiltrated, the cybercriminal will get all the hashes but will have a very difficult time converting the hashes back into the plaintext passwords. (We cover hashing in Chapter 4, “Cryptography.”) Salting is a way to ensure uniqueness when storing a password as a hash and reduce the chances of a rainbow table being successful. Without salting, if two people have exactly the same plaintext password, the hash that is stored in the database will be exactly the same. However, if a salt is added (for example, four or more extra random characters) during the hashing process, then those two plaintext passwords would produce two different hashes that would be stored in the database. These extra random characters make it impossible for a cybercriminal to obtain the passwords by using a rainbow table.
Don’t forget that a lengthy password does not eliminate the need for MFA. If by chance a cybercriminal tricks you into giving them your password via a phishing attack, MFA will save you, and then once you discover that you have given up your password, you can change the password and sleep better knowing that the cybercriminal did not get into your account.