MFA Series Post 1: Intro to Multi-Factor Authentication

-

At the recent RSA conference (2020) during a session on authentication, an audience member asked “Where would I go to learn about mult-factor authentication (MFA)? Which books should I read?” Nobody had a really good answer, and I was kind of embarrassed about it. Those of us who know about it picked it up over the years. I got my first multi-factor authentication token in 1998 or 1999 and built my first system that used it on the Windows 2000 Beta. However, MFA is one of the most important topics in security today, if not the most important one. We really can’t wait for the rest of the world to pick this up by osmosis over 20 years.

To do my small part to address this, I thought I would set down what I know, along with my opinions, in electrons. This article is the first in a series on multi-factor authentication. How many will there be? I don’t know. We’ll see. If you have something you would like me to opine on, ponder, or explain, please let me know. 

For this, first article in the series, I thought I would largely discuss terminology, and a little bit of technology. Some of this may be really basic, and I’ve tried simplifying a bit to make it approachable. If you already feel you know the all there is to know about all the terminology relating to multi-factor authentication you could skip this article, or you could read it and snark about how I over-simplified. 


If you do want to make sure you have some basics,let’s start with real basics. What actually is multi-factor authentication? For that matter, what is authentication? To understand that, we need to understand Identity.

Identity And Authentication

Identity Management (IdM) is the discipline of managing identities in a computer system. Going back to your fundamentals of computer security, you have subjects (actors) accessing objects (things). Subjects are often human beings, or things acting on behalf of human beings, but they can also be processes acting on their own. Each of these subjects are represented by one or more identities in one or more systems. For instance, you have a user name, an account that may have an email address attached to it, your Facebook/Twitter/LinkedIn/Amazon/whatever account, etc. All of those are identities in the respective systems in which they are being used. 


Identities are often thought of as username, and you can in some cases use the terms interchangeably. For human beings, identities are who we log into in the computer system, which could be a single computer, or a set of them. 

On the topic of “logging in” what does that mean? Well, it means that you authenticate yourself to the system. In other words, identity is who you say you are, and authentication is proving this claim. You authenticate by providing one ore more proofs of your identity, or authentication claims.


Before we leave the topic of identity, it is important to understand that in this context, when we say “identity” we do not mean it in a real-world sense. Your identity is relevant only within the system or systems that rely on whatever identity provider that identity lives within. For instance, your identity at work or school is probably provided by a Windows Active Directory or Azure Active Directory domain, or by a Google Accounts and ID Administration (GAIA) domain - your Identity Provider (IDP). It doesn’t mean anything except for systems that rely on that IDP - relying parties (RP). You may have several identities in that system, in fact. Some identities in those systems correspond to a single human being, but that is not always the case. 


However, for the purposes of what we want to talk about here, what’s more interesting is how you prove that the identity belongs to you. 

Authentication Claims

When you log in, you present one or more authentication claims. These are things that, presumably, only you can present that prove, with some level of assurance, that you have the right to use the identity you are logging in as. 


Authentication claims can take many forms. In the physical world you may show a passport, a driver’s license, an ID card, or just a note from mom and dad, as your authentication claim. In a system, you will usually present something the system can verify. In the simplest form of authentication, you present a username (the identity you want to claim, which is not secret) and a password (which hopefully is secret). Your password is a shared secret that both you and the system you are trying to log into knows (or at least can verify). 


The problem is, it’s typically unlikely that only you and the system you are logging into know the password. In fact, in most cases, the system doesn’t actually know the password. It knows something derived from the password. So, who else knows the password? Well, in a study I performed ⅔ of all passwords were reused so every other system where you used the same password knew them as well. If any one of those systems has been compromised then, well, pretty much everyone knows the password. At the 2020 RSA Conference, Microsoft reported that in January 2020 480,000 Microsoft accounts were compromised because those customers had reused passwords that had leaked from somewhere else. 

Single v. Multi-Factor Authentication

Using only a password to log into a system is known as single-factor authentication. Obviously, passwords aren’t the only single factors. Any time you present only a single authentication claim you are using single-factor authentication. 

If you need to present another factor, then you are using multi-factor authentication or MFA. Frequently, you will hear other names for it, particularly when two factors are involved. Here are some of the terms you may see:

  •     2FA - 2-factor authentication, i.e. using two authentication claims
  •     TFA - Two-factor authentication, i.e. the same as 2FA
  •     2SV - 2-step verification, also two-factor authentication, but implemented in two steps by a company that decided it was worth confusing customers with terminology to look cool.

You may also see “passwordless login”. Microsoft offers this using the Microsoft Authenticator app. This is really single-factor authentication. When you try to log in to, say, outlook.com this allows you to just type your username:


When you open the Authenticator app, you just pick the option for signing in. 

While this is, mostly, single-factor authentication, it’s quite secure, and in a later article I will discuss why. 

Could you have more than two factors? I.e. why don’t we just call it 2FA and not MFA? The answer is that, yes, you could. For instance, the system could authenticate the computer you come from as one it knows about, and then ask you for both a password and something else, and now you have three-factor authentication, which we should probably call 3FA to avoid confusion. 

What kinds of factors could you use to authenticate? I thought you’d never ask. 


Types of Authentication Claims

Broadly speaking, there are three types of authentication claims:

  1. Something you know
  2. Something you are
  3. Something you have

A password is something you know - something hopefully, but usually not, you are the only one who knows. Passwords are only good if they are secret, and two or more people can only keep a secret if all but one of them are dead. Other types of something-you-know factors included pin codes, pass phrases, code words, and those awful “security questions” that nobody in their right mind would ever use if they thought about it for about a second and a half. I’ll talk more about those in a later article. 


Something you are is the authentication claim that is most closely tied to physical identities. Using these requires you to identify yourself by registering some characteristic of yourself with the system, and then providing the same characteristic when you want to authenticate. Fingerprints are the most common characteristic as most people believe fingerprints are unique (they are not) and everyone has them (they do not). Other types of biometric authentication claims include retina scans, facial scans, genetic fingerprint, and a few other more or less pleasant ones. In a later article I’ll talk more about where biometric authentication is reasonable, but for now you just need to remember that you get very few of these, in some cases one (like your retina) or perhaps 10 (fingerprints) or 20 (if you take your shoes off). 


Something you have claims are where you prove possession of something that only you should have as your identity claim. In the example with Microsoft Authenticator above you proved possession of a pre-registered instance of the Microsoft Authenticator app that was allowed to approve a login. You also actually provided a “something you know” factor but I will talk more about that later. 


Most MFA is based on using something you know in conjunction with something you have. Virtually all authentication protected by MFA is stronger than authentication protected solely by something you know. In the comments to this article you will, however, find someone arguing about that, but I stand by the claim that any multi-factor authentication is better than no multi-factor authentication.


I will also argue that any business or service that does not support MFA today is putting its customers at risk. It’s very easy to implement MFA, comparatively speaking, and there is really no excuse for not doing it. 


Next time, we’ll start taking a deeper look at the something-you-have factors, talk about the types of them, and which ones are stronger than others. In a future article, I’ll talk about where something-you-are factors are a reasonable choice.

Comments

Post a Comment

Popular posts from this blog

U2F, FIDO2, and Hardware Security Keys

-
  In our journey through possession proofs we have encountered hardware factors of various kinds. HOTP and TOTP is often implemented as hardware devices, and of course, so are Smart Cards. In this post we will look at authenticators that implement the FIDO standards -  U2F, WebAuthn, and CTAP2. WebAuthn and CTAP2 are collectively part of the FIDO Alliance ’s FIDO2 protocol suite. U2F and UAF are older FIDO protocols that are supported under FIDO2. They can all be thought of as being part of the FIDO2 suite of protocols.  To understand these protocols, and their advantages and disadvantages, we need to be familiar with the three fundamental actors: Relying party (RP) - Also known as the server. This is the service that a user wishes to log into. Client - This is the application that brokers the authentication from the relying party to the authenticator and eventually the user. Much of the time, this is a web browser, but it could be any application. Authenticator - This ...
Read more

Single Sign-On

-
There are two kinds of organizations. Those that manage their single sign-on (SSO) system, and those that let their users manage their SSO. The other day I was in a discussion with a number of security leaders about how important identity management is to your security strategy. Obviously, everyone agreed that identity is very important. After all, if you don’t have a strong identity strategy pretty much no other component of your strategy will be strong. There is a reason that the first function of the NIST CSF is Identity.  However, the discussion then turned to SSO and whether it didn’t constitute putting all your eggs in one basket, and whether doing so is a good idea. Yes. SSO does constitute putting all your eggs in one basket. But, that is a good  thing. Why? Because you, as a security leader control  that basket. You know where it is. You know how it is configured. You have already required strong multi-factor authentication (MFA) on it. (You have right? If not, s...
Read more

Warning: Regulations May Harm Your Security

-
Like many of you, I have spent decades trying to devise security controls that comply with various regulatory requirements. In some cases, they are actual regulations, like FINRA 17a-4, GDPR, HIPAA, NYDFS Part 500, and PCI DSS. In other cases, the regulation is an industry standard to demonstrate adequate controls to business partners and customers, such as NIST CSF and SOC 2 Type II; or a requirement for some customers, such as FedRAMP. While every one of these is well intended and they all have some requirements that are sensible, they also have the potential to cause harm, primarily in one of two ways.  Regulatory Compliant Does Not Mean Secure Regulatory compliance is often presented as a voucher or certification. Management often celebrates that we “passed our certification”. First, most of the regulations are not actually certifications. For instance, as a merchant, you are not “certified” under the Payment Card Industry (PCI) Data Security Standard (DSS). You are assessed,...
Read more