MFA Series Post 2: Possession Proof Factors

-

Welcome back. This is a continuation of my posts about multi-factor authentication (MFA). Last time we talked about some basic terminology around MFA. The next step is to dive a little deeper into one type of authentication factors very often used for multi-factor authentication - something-you-have factors. To make this consumable, I’ll just clarify some more terminology in this first post, and then talk more about the various factors in subsequent posts. 

When you use a something-you-have factor you are showing that you have it in your possession - a possession proof. You may as a result hear these described as “possession proof factors.” You will also hear them referred to by the implementation. In this article we will discuss several types of possession proof factors and describe the relative strengths and weaknesses of each.


First, let’s clarify a little more terminology. 

  • Token - When used by itself, unless I say otherwise, I mean a physical hardware device. These can look like one of those credit card calculators that kids these days have never seen, like a USB flash drive, or like a cheap piece of plastic with a low resolution LCD display. 
  • User or Customer - This means the person who is trying to log into some account using some kind of identity and one or more authentication claims. 
  • Client - This is the computer or the software the user is using to log in with.
  • Identity provider (IdP) - This is the service that validates the authentication claims. If you have ever logged in with Facebook, Twitter, Google, Microsoft, or more recently, Apple, you have used an identity provider.  
  • Relying party (RP) - The relying party is a party that relies on another service, the RP, to perform the authentication. It trusts that the IdP has done this correctly. The RP needs to perform authorization based on the identity vended by the IdP. Typically, the RP is a service provider of some sort.
  • Service provider (SP) - This is the service that provides some service the user wants to use, email, shopping, whatever. The SP may be an RP using a different IdP, or it may be its own IdP, in which case the user has an account with the SP directly. Some are both. For instance. woot.com and Godaddy.com both have their own accounts in their own identity pools, but you could also log in using an IdP (Amazon in both cases, and Facebook and Google in the case of GoDaddy). 
  • Broker - In some systems you have a party that just acts as a middle-man (yes, like a man-in-the-middle). We can call them brokers. A broker, for instance, could collect authentication claims for a variety of IdPs and sort out which one should be used for a particular transaction. The broker does not actually validate the claims. They just collect and send them on to where they should be validated.
  • Server - This is an imprecise term that I will occasionally use as a short-hand for a combination of IdP, SP, and/or RP. I.e. it either implies that both functions reside in the same service, or that I don’t care because it doesn’t matter for the point I’m trying to make. 

In future posts we will look at a variety of possession proof factors and their relative advantages and disadvantages. 

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 is a thing tha
Read more

The Busy Executive’s Guide to Personal Information Security

-
Congratulations. As an executive you are the favorite target of ne’er-do-wells across the world. They will spoof email messages to staff and business partners in your name. They will try to hack your corporate account, your bank account, your email account, and your phone. In addition to hundreds of messages per week from semi-legitimate vendors who want to sell you their most recent search engine optimization snake-oil you will also get a variety of Word documents, PDF files, and PowerPoint presentations, most of which are laden with malware. If this sounds depressing, it is. It is the world of Information Security. There are ways to protect yourself, however. This document will tell you the most important things you can do. 1. Patch Your Stuff! The first thing you need to do is to patch. Software and hardware vendors provide regular security updates to fix security bugs. Or, rather, the reputable ones do. The first step is to use devices and software that provide timely and reliable
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, stop reading th
Read more