I have explained multi-factor authentication(MFA) to several people now. Most of them from my non-technical friends pile. Nearly all of them have requested additional information. I am either very convincing, or the world is indeed on fire. As such, I have decided to write this blog post. Hopefully someone will find it useful.
First things first, a disclaimer. I am not a security expert. I consider myself a security adept, an aficionado, or perhaps just a systems and network junkie who happens to care about security. There are much more in depth articles on this very subject, most of them fairly technical. My goal is to keep this post for the layperson. I would not mind if a few of my more security as a day job friends gave me their two cents on the statements I am about to make.
Here we go.
The first question a lay human may ask is, why does authentication even exist? What authentication boils down to is quite simple: it exists so that a computer and/or network resource can determine who you are. Based on that single fact, it can then perform the later stages of the entire login process. Namely, authorization: what resources are mine, and what actions am I allowed to perform? And accounting: What did I do while I was logged in? These three things are often collectively referred to as AAA. To ask what authentication is may sound like a silly question to many, but I have several clients who have worked very hard to eliminate authentication layers. Usually because they only see it as a burden. They do not see, or have not been shown, the advantages that proper authentication, when combined with authorization and accounting, can bring. Security be damned, proper AAA can actually make your enterprise work environment flow better. Without going too far off topic, done right, AAA can ensure that the right users can get to the right resources; meaning they can do their jobs effectively.
Dear Infosec peeps, I know, I am really broad stroking it here, as well as taking some liberties with some terminology. My goal is to explain the concepts and advantages, not the technical details.
What does this mean? When a computer or network asset knows who is requesting resources, it can deliver things like proper files, correct bookmarks for your web browser, grant access privileges for protected resources, your favorite songs, and even display your favorite background image. Everything about that computer service that relates to you, is tied to your digital identity, and the computer learns that identity via some authentication process. Some of this information is very innocent, like a background image. But a great deal of it is, to some degree, sensitive. A supervisor planning to fire Joe in accounting doesn’t want Joe to be able to read his emails. Authentication exists so that Joe can only prove to the computer that he is Joe, and not whomever he wishes to get some dirt on this week. Joe is a dick, and deserves to be fired. No, not you my actual friend Joe.
This of course leads to the question, how does a computer know who you are? The short answer is, it really doesn’t. It instead asks you to identify yourself, and then prove it. This is called a challenge response. Declaring your identity to a computer is fairly simple, the far most common method is to present a username. The username is your identity, not part of the proof of that identity. A username should never be considered a secret, I am nuintari nearly everywhere I go, with very few exceptions. This is hardly classified knowledge, and if it was, it would be a shitty example at that. Plenty of places auto assign numbers as account identifiers, but account identifiers are frequently not easily changed. If I needed nuintari to remain a secret, I am pretty sure I am fucked by this point.
In response to your proposed identity to a computing resource, there are three challenges that the computer can present for you to prove you are indeed who you say you are.
- Show me something you know (That I also know).
- Show me something you have (That I know you have).
- Show me something you are (That I know about you).
This is often stated in security circles as, “something you know, something you have, and something you are.” These are considered the three vectors of proper authentication. Each one has advantages and disadvantages. For sake of flow in this article, I am going to address them in reverse order.
Proving something that you are, is by far the hardest type to scale at a network, or internet scale. Something you are is often also called biometrics. Something about your physical self that uniquely identifies you as you. This is things like finger/hand prints, eye scans, voice stress analysis, and urine samples. Some of those were made up…… The reason these are hard is because they have to be distilled into something that can be potentially sent over a network, understood by a computer, securely in its own fashion, and be properly interpreted in such a way that a correct result is returned. All while maintaining that simply sending the correct digital message is not sufficient. Ergo, you have to prove you scanned your thumbprint, not just send a faked out image of your thumbprint. This exists, sort of, it tends to be expensive. It also is the least well supported. I highly doubt Facebook will ever accept semen sample authentication. Wait…… Facebook would totally do that…… You heard it here first, folks! Suffice to say, proving something you are is far more common in closed systems. Where all end points are controlled by a single entity. An example would be a place that requires hand print access to open certain doors.
A significant point to make about biometrics, that is often overlooked, is that they can never change. This may be considered a strength, or a weakness. When was the last time you changed your fingerprints? Again, this is both a strength and a weakness, and has to be evaluated when designing a security system. Broken record time: beyond the scope of this article.
Something you have is a little easier, and wonderfully, becoming far more common! This is tying a device to your account, and proving that it is in your possession at the time of the authentication request. The most common way most end users see this is the all so common RSA tokens that provide a one time password in the form of a short numeric code. Newer methods involve Yubikeys, or FIDO compatible devices.
Both devices present a response to the computer resource that you are who you say you, because you had previously agreed to tie that specific device to your account, and present it on demand for authentication. Yubi and FIDO work differently, but both resolve this challenge reasonably well. I have one of each for a variety of reasons, all beyond the scope of this article(I also have a backup in a fireproof safe, again, beyond article scope). I would be happy to do a rundown later, should someone want to read my ravings on that particular subject.
The most obvious reason to not like this is simple, you have to have a thing you carry around with you. We all carry wallets, key chains, and purses anyways, so get over yourself. Hardware tokens also come in a variety of qualities, and some can be cloned. Remember college? Those key fobs to get into the dorms after such and such an hour? Show of hands, how many of us had a fob that accessed _everything_? Oh, right, lack of a live studio audience….. trust me folks, it is a huge number of people. Basically, buyer beware, you probably get what you pay for.
Another form of proving something you have, is to use your cell phone, or other mobile device. The best example of this is the Google Authenticator App. Like the physical keys, you tie your mobile device to the asset you wish to connect to, and will be presented with a periodically changing code to enter when authenticating. Of the three, this is by far the easiest and cheapest to get started with, but also the least secure. Cell phones get stolen, and are far, far easier to match to an account than a random key chain thing. Also, you will frequently access computer resources, from the very device that is proving who you are to that very resource. Mind you, this is still far better than just passwords……
The far most common is number 1, something you know. I am talking about passwords. The exchange is very simple:
Computer: Who are you?
Computer: Yeah? prove it with a password:
Computer: Okay, I accept that you are nuintari, have fun!
The biggest problem with passwords is very plain to see, you all now know my super secret password. Passwords are just text, and can be shared. They can be sent via chat messages, accidentally typed into the wrong (possibly malicious) website. They are easily leaked, easily shared, and, if bad enough, easily broken given enough time. Some websites store passwords in plain text form, or in a very broken hashing algorithm. This means if someone pops their user database, they get your password too. This is why you should never re-use passwords, because the first thing a bad guy is going to do is try that password they lifted on other services you may use. Not only do passwords suck, but we suck at making them up. I’ll spare you the details, XKCD said it best.
So, what I am, the lay person to do?
The single best way to prove your digital identity to a computer asset, and prevent anyone else from doing so, is to insist on at least two of the above methods. This is called Two Factor Authentication, or 2FA. The most common method is to take authentication factors 1 and 2, and combine them. The authentication conversation then becomes this:
Computer: Who are you?
Computer: Yeah? prove it with a password:
Computer: Yeah, that is disgusting, show me your key.
Me: insert key, push button…..
*crazy crypto computer stuff happens*
Computer: Okay, I accept that you are nuintari, have fun!
This may not seem like much, but this is often the difference between a compromised account and nothing. A leaked password is still useless when presented with a second factor, and the end user can be informed that their password has been guessed correctly, many times, but the physical hardware device has never been presented. The end user can change passwords, with the sound mind that they dodged a bullet.
The flip side is also true, stealing someone’s hardware token is useless without also getting their password. Strong passwords are still very important in this scenario, because a lost hardware token can be revoked and replaced, so long as the password was not also lost, or just painfully obvious. This is also where it helps to have a backup token, stuffed inside a fireproof safe somewhere.
*ahem* Regarding passwords, street address, lower case, no spaces….. NOT A GOOD PASSWORD. Nor are phone numbers.
/me glares at clients $wePublish, $wePublishToo, and $weLawyerStuff…..
Using biometrics is also an option, but again, is the hardest to leverage at network scale. Using all three is also an option, making it three factor authentication, or 3FA. I have seen this done well before, it was impressive. As I stated earlier, biometrics work better in more closed systems, where the exchange of data can be more tightly controlled and trusted. This is hard to do on the public internet.
Some of you may be thinking to yourself that your bank does 2FA already. Sadly, you are likely mistaken, banks have some of the worst authentication systems for what should be extremely well protected assets. The most obvious is when they send you a code to your cell phone via a text message. This may seem like it is resolving the 2nd proof, but what it is actually doing is proving the 1st proof….. twice. You present a username, a password, and they send a code to your cell phone, which you also present. This used to be considered a valid form of the 2nd proof, it is no longer considered sufficient. What this is is now know as 2 Stage Authentication, of 2SA. You are still simply proving something you know, it just so happens that you only recently learned one of those two things. You haven’t actually tied the device to the account, you have tied something the device can learn to the account. This may seem like splitting hairs, but sadly, phone systems can and are compromised. Intercepting that code can be accomplished by a variety of means. In short, you don’t need the device that gets the code to prove identity, you just need the code, and the code can be separated from the device.
This may lead you to cry, but what about the Google Authenticator App? It does the same thing! Actually no, when you set a new account within that app, a secret is constructed that identifies not only the account which will need the code, but also what device the code is coming from. That secret is used to generate the periodically changing one time passcode on display. In short, if you have everything in Google Auth, and get a new phone without backing up and transporting those secrets, you are going to have a bad time. The difference between the Google Auth App and simple SMS based verification is that the Google App does indeed prove beyond a somewhat reasonable doubt that the correct device was used to obtain the one time passcode. The code can be separated from the device, but the task of doing so is significantly more difficult to accomplish.
This is not to say that SMS/2SA based verification is not worth doing. If it is the only option presented beyond passwords, you should very much take advantage of it. But ideally, the Google Authenticator app should be considered the base, bare minimum, and a physical hardware token, the gold standard.
In the end, I would strongly recommend everyone seriously look into 2FA. Google’s new Advanced Protection Program costs you the hardware, and a bit of time to adapt your habits. The devices you utilize for Google’s protection can be used for other services as well. Buy two hardware keys, authorize both of them with as many services as you can, then toss one into a fireproof safe. Congratulations, you do this much, and you are profoundly more secure than the average Tom, Dick, and Harry. You will find very quickly, that authenticating with the hardware device is very simple, and non-intrusive to your daily life. You’ve added five seconds to a task, and in exchange, reduced your potential ulcer count by a shitload.
Now, stop reusing passwords, and start using a secure password manager…… That is another article entirely.