O365 MultiFactor Authentication in depth–Part 1–what is multifactor authentication?

I wrote a quick post a few days ago about O365 and multifactor authentication but then I realized that many people don’t know what this is or why you might want it.  So, this is my primer on multifactor authentication as it pertains to O365.

First off, what the heck is multi-factor authentication?  For that matter, what is authentication itself?  In simple terms, authentication is the process you follow to identify yourself to a system and provide something to the system that then positively verifies your identity.  In other words you provide information to the system that only you should know to prove to the system that you really are you.  That is the authentication piece of the puzzle.  Once your identity is verified and authenticated the system can provide you with access to resources that you are allowed to use meaning appropriate security filters are applied based on your verified identity.  And, obviously, this can mean you have access to sensitive or private information that only you should have; you don’t want unauthorised users accessing your data.  All of this becomes critically important with Cloud services such as O365 as you are many steps removed from simple physical security measures (eg only you can access the PC that contains the data).  Also, there is a large movement to “claims-based authentication” which basically gives you access to data because you claim to be you.  Somewhere, somehow, the system needs to positively identify and authenticate your identity before it lets you go any further in this kind of scenario (and, yes, I have greatly simplified a very complex process, just bear with me).

For many years the basic authentication system was password-based; you supply the correct password for your account and you’re in and away to the races.  The problem with this is it really is not very secure and it really doesn’t do anything to authenticate your identity as anyone could login as you if they knew your password.  There is nothing in this process that is any more secure than a simple key in a lock – the lock neither knows nor cares if it is you turning the key, it just cares that the key fits.  If the key fits the person with the key is in.  So, in simple terms, a password-based system is not truly a way to authenticate anything as it is merely a locked door.


This kind of system can be beefed up somewhat with addition of some form of biometric scan like a finger print reader but while the scan is probably tied only to you (it is your finger after all), the process can still be pretty weak if the scan simply fires off a login with your ID and password in the background. This is the process that laptops and other devices follow when you fire up Windows and swipe your finger across the reader; you gain access but you really have not done anything different from  entering your login and password.  If, God forbid, someone got hold of your finger they could perform the same “swipe” and gain access to your system but, obviously, they would not be you.

Now, what if we “divorce” the biometric scan from firing off your login and password and, instead, require that you enter your login and password AND also require the biometric scan after that entry?  We now have a way to authenticate that the person supplying your login and password is most likely you because your biometric scan confirms your identity.


And this, in a nutshell, is multifactor authentication.  In very simple terms your claimed identity is authenticated by supplying two or more factors which, when combined, could only have come from you.  In many cases this is described as supplying something only you know, like your password (factor one) along with something only you have or are , like your fingerprint (factor two).  Put those factors together and you are authenticated to the system.  Once authenticated the system can also tell other systems that trust it that you are who you say you are or who you claim to be so the claims-based authentication process works across the board.

There are many different types of multifactor authentication available.  One of the most common and one that has probably been seen by the largest number of people is that provided by SecureID and other vendors through the use of a hardware “fob”:


The fob provides a number that changes on a regular basis (usually once per minute); you authenticate with the backend authentication server by providing your own 4 digit number as well as the number displayed on the fob – you provide something you know (your 4 digit PIN number) with something you have (the number displayed on the fob).  Again, multiple factors are provided and combined to authenticate or prove your identity.  This type of system can also provide the same generated number (like on the fob display) through software that can be installed on a PC or a smartphone.  You run the app and get the generated number which you then input to the authentication system along with your PIN.

Microsoft uses a similar approach with multifactor authentication in O365 in that it relies on your smartphone as the thing you have which it combines with the thing you know – your login and password – to authenticate you.  O365’s multifactor authentication process can send you a one time use“PIN” to your smartphone as an SMS message which you enter as required.  You can also have the system configured to call your phone to provide you with the PIN.  Either way, the system is positively authenticating your identity before it grants you access to O365 resources.

My next post will dive deeper into the actual processes inside O365.