Identity and Authentication Detangled
Identity management, Authentication, and Authorization is hard for many people to understand. But it doesn't have to be, if you take a few minutes to understand the core principles:
- Identification - Who do you claim to be? - Your Username
- Authentication - Can you prove you are that person? - Your Password
- Authorization - What are you allowed to do? - The Roles/Groups you are in
Taking Advantage of Joe
Consider a real world scenario where you find a bank card for somebody named "Joe"—this is a form of identification for Joe and his bank account.
Feeling a little felonious, you take this card to the bank and tell them, "I'm Joe, give me all my money."
You have Identified yourself as Joe... But, the bank doesn't know if you really are Joe or not. Just having his card is not sufficient.
To help them know for sure, they have put additional measures in place, like requiring photo identification, this is a form of Authentication. Or even better, also requiring an account PIN, which can be a second factor in addition to the first.
More than a single factor is desireable with authentication, because one factor might be compromised. In our scenario, you could possibly bring a fake ID—but ideally Joe isn't writing down his password, it is something only he knows, so losing is card isn't so disasterous. But, We'll come back to multiple factors in a moment.
Without being able to prove you are Joe, you do not pass Authentication even though you have Identification and the bank has successfully thwarted your attempt to get all of Joe's money.
But consider what if you, for some reason, had forged Joe's identification, and also knew Joe's PIN?
Is Joe Authorized to withdraw all of his money? Joe could have put a block on his account, or the account could be setup with a control requiring a second person to Authorize any withdrawals.
From this you can see the distinction between Authentication and Authorization. Having Authenticated access to something doesn't necessarily mean you can do actions with it, without the proper Authorization.
Authentication is the central thing that secures a given transaction. It is how we assure that you are who you say you are. Identity, on its own, is untrustworthy, but Identity combined with Authentication begins to introduce trust.
The lack of Authentication is also what allows such rampant abuse of personal information in the financial industry, such as with Equifax, but that is a separate converation.
Multiple Factors of Authentication
In the previous example I also introduced the idea of multiple factors, such as a photo ID in addition to a PIN number. Each time you properly add another factor to Authentication, you dramatically reduce the risk that it can be compromised. This is why everybody is so excited about Multi Factor Authentication (MFA), sometimes also referred to as Two-Factor Authentication (2FA).
The central part of MFA is that you have different factors that must come together to prove something. Usually, this is a combination of something you know, combined with something you have. This could be a photo ID, combined with a PIN number.
However, if you add the same type of factors, such as two photo ID's instead of one, it doesn't really increase the strength of the Authentication because they are both something you have, any of which could be stolen.
The problem is compounded in that many times what you know is also something you can write down, turning it into something you have. This is where time-series codes have come into play. These are some form of a code, such as digits, which you can submit as a factor along with your other factors. But the difference of a time-series code and a PIN, is that the time-series code expires fairly quickly—usually within a minute.
If you have ever used Google Authenticator, you have used a time-series code. The value of this is in the quick expiration. Consider: even if somebody was able to intercept or see it, the value of using it disappears quickly enough they aren't able to leverage it. It is a balance between convenience and security.
Why SMS is not a second factor
For time-series codes to work properly, they must be established during a separate and out of band Authentication cycle.
The common but insecure practice of sending you a code via SMS which you then input into a website does not meet the real criteria of being a second factor, because SMS (and email, or any other messaging protocol) is itself similar to a trust level of simple Identification. It can easily be spoofed.
Consider the scenario with Joe's bank card. What if instead, the teller also asked for a special time-series based PIN number, and said, "So... I will send you the number you need to give back to me so I can be sure you are who you really say you are."
And then they wrote a number on a piece of paper, put it into an envelope, placed it into the mailbox and waited for it to get delivered.
While that envelope is in transit I can intercept it—I could even get it before it left the building, possibly. So in essense, the teller may as well have just handed the code to me, for me to hand back to them, for all the additional security it provided.
To do time-series codes properly, Joe would have setup a special number sequence with the bank when he opened his account. With this in place, the teller instead says, "I need you to do this math problem, and insert into it the special number you were given when you opened the account, along with the current time. The result is the code that will then let you get your money, at least for the next minute."
With this code synchronized out-of-band, combined with the time of day, it makes this a much more valuable second form of authentication.
I hope this was helpful to understanding core concepts. When I get time, I will add a followup post connecting this into the technical level concepts. Thanks!