Introduction to Azure Active Directory Part 3: MFA Primer

chdelay

Azure MFA is a very complex topic, but I’m going to attempt to cover it in one blog posting. Below is a brain dump of all the thing to think about when it comes to MFA, but I’m sure I’m missing something.

  • MFA Registration
  • Step-up authentication scenarios: These include Identity Protection, Privileged Identity Management, and I believe Authentication context.
  • Conditional Access
  • Secure defaults
  • Understanding when you are and are not prompted
  • MFA methods

Basic Terminology

This is for those that are new to IT or IT Security (or CyberSecurity which is the fashionable term these days). We all start somewhere. These are my definitions.

Authentication: Shorthand for authentication is AUTHN. This is the process of a digital identity proving that it is in fact that identity. For example, a user proving they are that are the user that is represented by a user account. The user typically proves this by entering a password. Keep in mind not all identities are users. There are many types of identities and different types of systems have identities. For example, Active Directory has user accounts, computer accounts, and managed service accounts.

Authorization: Shorthand for authorization is AUTHZ. This is the process of determining if an identity has permission to access a resource. This resource can be but is not limited to data and applications. Resources can be controlled by rulesets and Access Control Lists (ACLs).

Identity Provider (IDP): And IDP provides authentication services. In other words, it authenticates identities. To authenticate identities and Identity Provider maintains identities such as users.

So, what is MFA?

There are several different factors you can use when authenticating. And the source of those factors come from 3 places. Something you know, something you have, and something you are. The more of these that you use to authenticate the more secure the authentication will be. And what we mean by secure is that the IDP authenticating you has a higher confidence that it is you based on how and the number of ways that you authenticate. Keep in mind some authentication methods may use more than one authenticator. For example, if you use a smart card to login, it uses something you have (smart card), and something you know PIN. Anyways, here are some common authenticators:

Factors

Something you know

Examples: Password, PIN, answer to a security question

Pros: Easy to manage, does not require any additional hardware or software

Cons: Can be stolen or compromised

Something you have

Examples: Smart Card, FIDO 2 Key, Windows Hello for Business enabled laptop, Authenticator app

Pros: Less likely to be stolen or compromises. Usually, they require a second factor. For example, FIDO2 keys usually require a PIN of fingerprint, WHfB requires a PIN or biometric, Authenticator app requires you to unlock your phone, and so on.

Cons: More complex to manage due to the fact that there is hardware that must be distributed and maintained. Also, processes must be in place to replace lost or stolen devices.

Something you are

Examples: Fingerprint, facial recognition, and retina scan

Pros: Management is minimal since the user is the authenticator. Also, it can be used across multiple devices.

Cons: Some people have a misunderstanding that their fingerprints or other biometrics can be stolen. Some support may be required for the enrollment process.

Why use MFA?

I can’t really express how important MFA is for securing authentication. MFA dramatically increases the security of authentication. And this is because it increases the confidence that the user is actually who they report to be. And once again this is because passwords are very commonly compromised. There are just so many attacks against passwords. Some ways passwords can be compromised:

Shoulder surfing: watching a user type in their password

Password re-use: For example, a user uses the same password for all their accounts. There is a password breach with one of their accounts due to weak security of the organization. Now the password for all their accounts is compromised.

Password breach: An organization stores passwords in an in-secure way or the password for a password vault is compromised. You see a lot of red team exercises where admins use a password vault that gets compromised. I have also seen passwords sniffed from chat conversations and also from authentications that do not use encryption. Active Directory Database being dumped can be another source of passwords for attackers. Rainbow tables can be used if you have a password database to determine the password.

Brute-force attacks: Guessing every possible password until you guess one that works. A lot of IDPs have throttles and account lockouts that make this type of attack less likely to succeed.

Authentication Methods/Factors

In this blog (Introduction to Azure Active Directory Part 2: Authentication Methods – xdot509.blog), I covered most of the authentication methods/factors that can be used to perform MFA. The one I did not cover is Windows Hello for Business. This is not going to be a lesson on WHfB. I am just discussing it in relation to MFA.

With WHfB you can of course sign in with a username and password. This is of course not considered MFA. However, there are some other options. You can use PIN, facial recognition, or thumbprint. One concern is that a PIN might be similar to a password. And it is not similar. A password is a shared secret that both parties need to have to authenticate the user. So, the server and the client both must have a copy of the password or a hash of the password for authentication to work. PIN is different because it is unique to the device and only authenticated on the device, which then uses it to unlock keys that can then be used for secure authentication.

Anyways, unless you are using username and password with a WHfB machine, then you are performing MFA. This means if you have conditional access policies that require MFA, MFA will be satisfied. The mechanics of course is a little more nuanced than this.

So, there are 3 types of tokens in the scenario that I am going to cover. A Primary Refresh Token which can be used to request additional tokens (access tokens). Refresh tokens which are usually application specific. So, an RT for Outlook can request an access token for Outlook. If a user attempts to access Outlook, the system will attempt to locate an RT for Outlook. If it has an RT, it will use the RT to request an AT. If it does not have an RT, then it will use a PRT to request an AT.

When you login with WHfB using an MFA method, the PRT gets the MFA claim added to the PRT. PRT is valid for 14 days and sign-in frequency is set to 90 days. However, if the user is active the PRT will continually be refreshed. Which means that if a user authenticates with a WHfB MFA method that claim will persist in the PRT until the 90-day mark. So, people being people, they get excited about this, and not in a good way. They feel that there is some degradation of security because the MFA claim persists. But this is borderline idiotic. Because even though the MFA claim persists in the PRT, that PRT is only associated with the MFA method. For example, if I login with fingerprint on a WHfB machine that MFA claim will persist in the PRT that is associated with fingerprint login. But so, what? The user is still going to use a fingerprint to login every time and so does it really matter whether the claim gets injected every time or persist.

Now to be fair there are situations outside of WHfB MFA where it will persist as well. So, username and password on a WHfB machine is not MFA. But if after I login I get prompted for MFA while accessing an application, I know have an MFA claim that can persist with username and password. So, why is this? Azure AD is designed to minimize prompting the user as much as possible, and it is very easy to correlate this to security in the physical world. For example, when you started your job, you were required to bring in a government ID on your first day to verify your identity or in other words to authenticate. That ID along with some paperwork from HR allowed you to get a proximity card that allows you to enter the building. So, think of the government ID and the HR paperwork as your MFA. Once you passed this MFA you weren’t checked again. You just used your PRT (proximity card) to continue to access the building. It would be silly for you to bring the HR paperwork and your government ID every day to enter the building. And using that same login we can see that it requires the user to perform MFA every time they access an application as at least equally silly.