Checklist 41: Open Sesame: Authentication and Online Security
On this week’s episode of The Checklist, we’ll be covering authentication, authorization, and the difference between them.
We’ve spent a lot of time talking about password security in the past and the reasons it’s so crucial for us to get it right. Why are we increasingly encouraged to abandon the usage of just a password on its own? Why do we need 2-factor or multi-factor authentication? Today we’ll break down those answers and more. First up, it can be helpful if you understand the way authentication practices have developed and evolved over time.
- Why do we even need authentication?
- Authentication is not the same thing as authorization!
- Three major categories of authentication factors.
- The three types of authentication, explained.
- Why even two-factor authentication isn’t perfect.
Why do we even need authentication?
We’re all familiar with the situations where we use passwords and we understand why we need to use them. If someone is going to go on Amazon and make a purchase with their credit card, they should be able to prove they’re allowed to access the account. The same principle applies whether you’re logging in to social media or running licensed software. Authentication isn’t merely the act of supplying a password, though.
From a user’s perspective, you punch in your username and password, press submit, and then, assuming you avoided typos, the site opens the door for you. Behind the scenes, though, there’s a lot more going on: the website needs to determine the validity of your password. More often, it may need to do even more than that by authenticating that we’re also the actual owner of that password. An additional step, authorization, can also occur, especially if we’re talking about computer or software systems. We’ll touch on that in a minute.
We need this complex but largely invisible process because it’s a fundamental element of security. Otherwise, no one would be able to have private, personal accounts, and anyone could impersonate anyone else. We need authentication because we need a reliable way to safeguard secure, sensitive data. But how does your computer or a website or anything else know whether you’ve supplied the correct password?
Early on, we relied on the most basic method, one that would make computer security pros everywhere shudder today — plain text storage. After creating your account, a server would store your username and password pair in a database “as is” – it’s like writing your information down on a post-it note and putting it in your desk drawer. When you sent a login request, the computer would just compare what you sent to what it had on file; if it matches, you were authenticated.
This method hasn’t been the case for a very long time outside of the absolute most insecure sites. Storing passwords in plain text today would be grounds for a security scandal! And for good reason: all it takes is for one clever hacker to break into the server and steal the database table for everyone to have a problem. Storing passwords in the clear is easy, but provides no security for your password, or your private information.
Today, the primary method for storing passwords and authenticating user input later is called “hashing.” Now, at its root, hash functions and algorithms are very mathematically complex. They must be to provide good security. What these are not, though, is “encryption.” That implies something else altogether: namely, that if you have the correct decryption key, you can unlock whatever you encrypted to start. That’s not the case here; once a password has been hashed, it is (ideally) very difficult to work backward. That’s the point!
Let’s briefly explain how hashing works. When you create your password for the first time on a website, the server applies a complex mathematical function to the text after it is converted into binary information. The nature of these algorithms varies depending on the hash method used, but the general idea is the same for all of them. To introduce variations, modern hash functions include what is called a “salt” — a random value assigned to your password during its computation. The result, after all the math is said and done, is an alphanumeric string of fixed length. The website stores this string securely along with the original salt value.
When you go to log in again, the password you entered is hashed using the salt value stored with your username. The system then compares the hash of the password you entered against the hash stored for your username. If the two hashes match, you’re authenticated and can access your account. This entire process is the foundation of a great deal of authentication around the web, as it prevents secure information from passing over insecure channels.
It is very difficult to work backward from a hash to derive the password itself. That’s especially true with modern algorithms which use both very long strings and complex salting methods. Think of it as like being asked to factor a huge number. When you multiply numbers together, getting the answer is easy. Tell someone to take that huge number and figure out what you multiplied to get it, and suddenly the task takes much more time.
There’s a lot more that can occur with hashing, but now you understand what’s going on behind the scenes. It’s the technology that powers our ability to authenticate ourselves to digital systems safely.
Authentication is not the same thing as authorization!
A little earlier, we mentioned that authentication can go hand in hand with something else called authorization. At first glance, it’s easy to get the two confused. You might think: an authenticated password authorizes me to access my account, right? That is partially correct, but in the security field authorization goes deeper than that. In fact, authorization plays a big part in computer security, especially when it comes to protecting yourself from malware. It’s a whole different ball of wax.
If authentication is the process of proving you are who you say, then authorization is the process where the system figures out what you are allowed to access. To revisit our Amazon example, you don’t suddenly gain the site administrator’s privileges when you log in with your consumer account. Why not? The site needs to determine what level of permissions you have to move forward. So basically, authorization is a check on what you’re able to do with valid authentication methods. It also opens the door for “guest” users and non-authenticated computer usage.
Access control through carefully delegated permissions and authorizations demand robust authentication. Otherwise, your system will never have a reliable way to tell who it should allow to undertake what actions. Before being allowed to add or delete files from the hard drive, install software, or muck around on the machine in any way, proof is required. So, after authenticating your identity with your password or the other factors we’ll soon go over, the machine “authorizes” you to undertake certain actions. A guest user on a library computer can’t wipe the operating system, but the system admin can.
Software authenticates itself within your computer, too, though it’s a little different. For example, have you ever heard of code signing? Code signing is a method developers use to guarantee that the software supplied is valid and safe to run — with no alterations or nasty hidden surprises like a keylogger or other malware. Code signing uses digital signatures, which use hashing techniques, to verify the code you received is the exact copy of what the developer published. If you’ve ever read Apple’s patch notes, you’ve probably seen the fixes that relate to issues of authentication and authorization.
We talk about this a lot when certain types of malware bypass, defeat, or exploit system security so it can run code without proper authentication. Sometimes the malware finds a way to bypass the authentication process, which fools macOS’s Gatekeeeper into thinking the malware is legitimate software. This results in the software becoming authorized to run on your computer.
In some cases, like on websites full of personal info such as social media or banking sites, you must authenticate yourself more than once to gain additional authorization. Someone who is logged in to their Facebook account, as one example, must re-enter their password to do something like add a phone number or delete their page. Re-entering a password is a way to re-authenticate a person to ensure they are indeed who they say they are. This is important because many of these sites, after you login, keep you logged in so you don’t have to put in your username and password each and every time you visit the site. That’s why re-authentication is a good and valid check when making updates of sensitive information to your accounts.
Three major categories of authentication factors.
So, since authentication is all about proving your ownership of an account and gaining access to something, what are some of the ways we do that? In this area of the security world, you’ll hear the word “factor” thrown around a lot. Factor is a bit of industry jargon to refer to the different methods we have for authentication. With that in mind, the categories for the “authentication factors” we use break down into three main groups. That’s right — there’s more than one way to authenticate yourself than with only a password. In fact, you’ve probably already done it before, even if you didn’t think about it at the time.
What are these factor categories? Generally speaking, there are knowledge factors, inherence factors, and ownership factors. All together these cover a lot of ground and encompass many ways to identify yourself. They provide us with a lot of potential combinations, which makes it harder for someone to impersonate others. Some of them are only useful in limited contexts, while others have some pretty broad applications. Let’s start by looking at knowledge factors since they’re by far the most common type today.
We’ve talked about usernames and passwords quite a bit. These are knowledge factors – sometimes referred to as “something we know.” It’s relatively easy to remember only one password — but it can be a challenge to remember many. Therefore, on its own, a password is not enough to provide true security. Many people re-use passwords across multiple websites. Words like “password” and strings such as “123456” are all too common.
A password isn’t the only knowledge factor, however. There are also secret questions.
You’ve already encountered secret questions when setting up an account or trying to reset your password. These are questions like “What is your mother’s maiden name?” or “What was the make of your first car?” The idea is to create relatively unique identifiers that only you can answer. The questions asked have become much more specific to reduce the chance someone could guess the answer. Random guessing is also why websites often require three or more secret answers. A PIN, like you punch into your bank ATM, is also an important knowledge factor.
However, even taken together, knowledge factors aren’t enough today. Social engineering, keylogging, and other methods can all leave these elements vulnerable to interception or theft. That’s why we also use ownership factors in increasing numbers. Ownership factors are something you own or have possession of, and it comes in plenty of different forms too. One ownership factor you interact with regularly is your bank card. When you want to get money out of an ATM, you don’t just punch in your PIN and get cash; you need to insert your card, too. This same principle applies to computers using what are often called “tokens.”
Tokens come in many shapes and sizes, and not all of them are physical. Have you ever used Google’s Authenticator app or a security key application for an online game? These are ownership factors. You own your smartphone, so it’s assumed that if you can authenticate yourself on the phone, the app can generate a secure key for you. Websites that send you a text message with a one-time code are also supplying you with an ownership factor. Software-based keys such as this are increasingly common, but hardware dongles, like the RSA SecurID, still exist and are in common use.
Some of these hardware units communicate with a home server to verify validity. Others, like the SecurID, are fully offline and generate random secure strings based on programming within the device itself. The server authenticates this through a complex algorithm. Other hardware keys plug in to your computer — this is often the case in some sensitive applications.
Finally, we have inherence factors, which may be the simplest of all and yet the hardest to duplicate. These are things which are inherent to each individual and thus unique by nature. Your voice, for example, could be used to authenticate yourself. More commonly, smartphones today often include a fingerprint scanner for quickly unlocking your phone or making a payment. The iPhone does this, and Apple recently put that technology into the newest MacBooks. The pattern of your retina might be something you use to authenticate yourself in the future.
Inherence is all about biometrics, and provide an excellent level of security, but biometrics also come with some understandable privacy concerns. If someone is going to store a copy of your fingerprint or voiceprint, it should be behind the strongest digital lock and key possible! However, again, even this is not entirely 100% secure; there are methods for duplicating your fingerprints in some cases. Biometrics is still an emerging field within authentication technology. Even so, they’re starting to play a more important part in authentication procedures.
The three types of authentication, explained. As we mentioned, the three authentication factors can create opportunities for some pretty secure access and authorization methods. As a result, the way we identify ourselves digitally is undergoing a major shift. Two-factor authentication is more than a buzzword now — many major sites have it as a cornerstone of their login security systems. Certainly, some of the biggest companies, like Google, Facebook, and Twitter, all see the value in adding new layers of complexity to their login systems.
When you hear “two-factor authentication” does it make you wonder if there are other types? There are — but what is two-factor, or 2-F-A? It’s all about taking the identity factors we discussed earlier and putting them into practice. Single-factor authentication is the most common, and it’s exactly what it sounds like: you supply a single secret piece of information for a computer to validate. If it’s legitimate, you gain access. If it’s not, you don’t. Either way, you do not need to supply anything else.
Your iPhone allows you to use the inherence factor of a fingerprint to unlock it, while your email account (usually) only requires a password. Either instance is an example of single-factor authentication at work. Unfortunately, we shouldn’t depend solely on the security of a hashing algorithm to keep us safe. There are a ton of reasons why single-factor authentication is vulnerable to compromise. We’ve covered why passwords can be vulnerable already. While you might get by with single-factor authentication in some cases, a more rigorous approach is better. That is where two-factor authentication comes into play.
The most common way to encounter two-factor authentication today is through a combination of a knowledge factor and an ownership factor. A text message often comprises the ownership factor. When you try to log in to a website where you’ve enabled 2-Factor Authentication, entering a correct password will trigger the server to send a message to the phone number on file. You then get a one-time code that is only valid for a few minutes. After the server verifies it is the correct code, you cannot use that code again. However, you’re now authenticated and able to access the website.
The Google Authenticator app works roughly the same way. The RSA SecurID was one of the first and most popular two-factor solutions for a long time. It was a hardware token that people typically attached to their keyrings or work badges. Now that smartphones and texting are everywhere, though, hardware tokens that are easily lost or stolen have decreased in popularity. Instead, RSA now also offers keys tied to your phone itself. Overall, 2-Factor Authentication offers a huge leap in security even if it sacrifices some of the convenience of an instant login. No matter how many of your passwords a hacker steals, they’ll have trouble breaking into your account without your phone. The mere presence of 2-Factor Authentication can act as a deterrent in some cases, sending bad guys on to other targets.
Multi-factor authentication, or MFA, also exists, though in a much less widespread form. Few people face such huge security demands that they need to present three separate instances of personal info to authenticate. However, it can and does happen — and not just in super-secret government installations inside the CIA or NSA. MFA requires ownership and knowledge factors and the presentation of a biometric identifier, too.
Retinal scans and voice identification are often the most common components in MFA set-ups. You might also encounter MFA where you need two ownership factors and one knowledge factor, or any combination thereof. As we face greater security challenges, this path might experience the same growth in popularity 2-Factor Authentication is experiencing today.
Why even two-factor authentication isn’t perfect.
As we add more layers to our security and depend on our computers to hold larger amounts of our private information, strengthening our authentication methods makes perfect sense. That doesn’t mean that we’ve perfected everything, though, or that two-factor authentication will always be enough to keep unwanted individuals away from your accounts. Someone is always looking for ways to compromise or undermine the integrity of these systems. After all, if we had a perfectly secure way to authenticate and authorize, we would hardly ever have to worry about identity theft or malware! That isn’t the case, though.
Two-factor authentication can fail in several ways, and there have been some notable incidents where breaches occurred. It doesn’t mean you need to be fearful or an inability to protect your account — only that you should be aware of how important good practices are! So, what are some of the instances where 2-Factor Authentication has come up short?
We’ve mentioned the RSA SecurID a few times today. When it first came out, it dominated the market for years as the most viable 2-Factor Authentication solution. Then, in 2011, the company was forced to drop a bombshell on its consumers: SecurID had been compromised. RSA employees had been fooled by phishing emails into opening fake Excel files loaded with malware. After the payload installed onto the computers, hackers entered RSA’s servers and stole unknown quantities of data. The company has kept most of what was stolen under wraps to prevent the hackers from manipulating the data.
Later in the year, a major defense company suffered an attack that was reported to be related to the SecurID breach. RSA then offered to replace the hardware tokens used by any of its customers. They took this action to ensure that the secret data used to create unique token keys was brand new, and in no way related to the compromised server. This incident demonstrates the incredible power phishing has to impact security — and the unexpected ways in which 2-Factor Authentication might be compromised.
Other issues can cause failures of 2-Factor Authentication as well. Late last year, PayPal had to issue a patch for their two-factor system that used security questions. Simply changing a value in the HTTP request sent to the server would allow the username and password alone to provide authentication. While breaches compromising the actual integrity of the keys sent are rare, attackers always look for ways to work around the need for 2-Factor Authentication.
Social engineering is a risk with multi-factor authentication, as you could be tricked into giving up a code to an attacker. Some individuals trying to engineer their way into Google accounts would send an official-looking text message to users requesting a 6-digit code. They would then attempt to log in to the account, triggering a 2-Factor Authentication text. Obviously, a close look at this would tell you that it isn’t for real, but that won’t stop some people falling into the trap.
Some social engineering efforts cut you out of the picture altogether. In several cases, determined attackers have gained access to accounts by calling companies and impersonating users. They convince the person on the line to disable 2-Factor Authentication or redirect the authentication codes to another number. As a result, there is concern that SMS messages may not be the best way to provide authentication codes. A secure and encrypted app that generate a key may be a better solution.
Attacks directly on the authentication procedures can yield some success too. In 2014, hackers used a phishing campaign to distribute a fake Android 2-Factor Authentication app. Rather than generating keys, this app was malware disguised as legitimate software. Anytime you received a 2-Factor Authentication text, such as from a bank, the message would route to the hackers instead. Efforts like this to compromise or circumvent 2-Factor Authentication are ongoing. Though there have been few notably large breaches that caused damage, it’s clear that there are still security concerns here – and hackers won’t stop trying to work around these systems! Hardened systems and a continued exploration of how to improve the identification factors we use can help to mitigate some of these risks we face.
Next time you enter your password into Facebook, or you type in a 6-digit code from Google, stop and think about everything that’s happening behind the scenes to keep you secure. We’re entering an age where single-factor authentication may soon go extinct for all but the most basic authentication needs. Identity theft and security concerns continue to drive us towards a world where we regularly use a wide variety of factors to authenticate ourselves. With that in mind, we’d like to end today with one last question for you: Have you enabled 2-Factor Authentication yet?
