8 Key Authentication Terms You're Probably Misusing
Whether it’s in whitepapers, news stories, sell sheets, or on display at trade shows, industry jargon around authentication is practically inescapable. In today’s threat landscape, there’s certainly justification for keeping these topics front-of-mind and sparking conversation.
But when authentication concepts start to get a little tangled, it can be hard to know if you’re speaking the same language as everyone else. Let’s dig deep and explore what eight widely used authentication terms actually mean. Along the way, you’ll see just how complex the world of authentication can be.
1. Strong Authentication
Strong authentication is one of those industry terms that’s gotten thrown around so much, in so many contexts, that its significance has been blurred. Thanks to marketing lingo and an inconsistent approach to standards from different governing bodies, “strong” has ended up synonymous with “doesn’t use a password” or simply, “not weak.” In reality, a consensus meaning for strong authentication does exist, and it may not be what you think.
Read More CloseMany people consider strong authentication to be the same as multi-factor authentication (MFA) or two-factor authentication (2FA), but if you examine the European Central Bank’s standards for strong customer authentication, there are a few more hoops to jump through than just having more than one factor:
- There have to be at least two methods used to authenticate. These two methods should come from these three categories: something only the user knows, something only the user has, or something only the user is.
- The methods used have to be independent of one another, meaning if one is breached, the others aren’t automatically compromised. One also has to be non-replicable (unable to be duplicated), unable to be stolen through online means, and not reusable.
As you can see, there’s more to strong authentication than simply “more than one,” when it comes to the ECB. However, with the U.S. National Institute of Standards and Technology (NIST) definition, it is that simple—only "requiring two-factors in order to authenticate.” Even so, NIST’s most recent Digital Identity Guidelines update gives a lot more detail on what makes a factor acceptable and what contributes to authentication strength.
Here’s a caveat, though: this term, like any term based (however loosely) on codified standards, can be a double-edged sword. Just because you’ve complied with standards doesn’t mean you’ve chosen the most secure or appropriate mix of authentication factors for your organization. Compliance matters, but strategy and thoughtful implementation matter too.
2. Authorization Creep
To understand the problem posed by authorization creep (and get a clear sense of what the term actually means) you first need to understand the difference between authentication and authorization. Authentication is when a system determines that you are who you say you are. Authorization is when the system determines what you have the right to do within the given network or application, given your authenticated identity. That’s where things can get tricky.
Read More CloseThe problem with authorization creep, also called privilege creep, is that the threat it poses to your organization will typically have nothing to do with the strength of your authentication, but instead is all about your policies, oversight, and the ease of managing your system. The fanciest, most high-tech authentication protocols won’t mean a thing if legitimate users are over-authorized. Pretty creepy, right?
Authorization creep is a function of access aggregation, which isn’t necessarily a bad thing. Over time, members of your organization might change roles or acquire more authority, resulting in them gaining access to new systems. If you’ve got a secure sign-on (SSO) framework in place, this can make things easier for legitimately authorized members to do their jobs and function in a complex networked ecosystem.
Where it can cause a problem is when users start to accumulate access rights without getting rid of old ones, resulting in an over-authorized user. The way to combat this issue? Regularly reviewing and auditing access rights for members of your organization and enforcing the principle of least privilege (PoLP), which limits privilege to the least amount someone needs to function in their role. Thankfully, the right identity and access management (IAM) system will facilitate that review to help prevent employees from becoming super users that have illicit access to far more systems than they should.
3. Biometrics
Bio – from the Greek root for “life” Metric – from the Greek root for “measure” When it comes to biometrics, you may not be totally sure what these “life measurements” are, or why they’re such a dominant force in authentication. That’s okay, because this is another case of marketplace overuse (and a healthy dose of Hollywood) interfering with the meaning of a key authentication term.
Read More CloseIn the authentication framework, biometrics are a factor linked to something you are, and they can be incredibly difficult to steal, spoof, or lose. That’s what’s so strong about them. Typically, people think of biometrics as things linked to physical characteristics—like eyes and fingers. They’re something you’re born with, right?
Not necessarily. Yes, physical characteristics that you’re born with still account for the largest portion of biometric use cases. These inherent factors are in widespread use today. But there’s another category: behavioral biometrics. These “life measurements” are acquired over a lifetime and may change subtly, all while remaining as unique as a fingerprint.
Your voice, gait, your way of typing, and a whole host of other unique characteristics are all a part of this group. And while a certain spy movie that shall remain nameless probably has you thinking that gait biometrics (and behavioral biometrics as a whole) are just for super high-tech black sites out in a desert, that couldn’t be further from the truth. Behavioral biometrics are already in use as a piece of risk-based authentication on plenty of websites, working behind the scenes.
4. Federation and 5. Single Sign-On
You know the rectangle/square analogy? When talking about federation and the often-associated term single sign-on (SSO), you may see that analogy being thrown around with very little clarification actually given about what the difference is between the two, or why it matters. You may also be wondering how you’re logged on to so many websites without actually signing into them. It’s all related—and it’s all a part of how user identities and access get managed in complex, intermingled domains.
Read More CloseTo nail down the differences between these two terms, let’s start by explaining the comparatively simple structure of an SSO authentication environment. Basically, single sign-on allows you to sign on once with a service provider for a range of services, allowing that one authentication event to give you access to a suite of services. There are plenty of services that enable SSO, and the beauty of SSO is how frictionless it is for users. (It also may let crooks get access to way more services than they would if SSO weren’t implemented, but we’re not going to worry about that right now.)
Federation works slightly differently, as it isn’t just requesting access from a single service provider. There’s still one sign-on involved on the user’s end, but not on the back end. Instead, federation relies on a trust relationship between multiple service providers, with a single source for that trust. So, the user signs on to the source of the trust relationship (a centralized identity provider, or IDP) with all of the necessary credentials once. Attempts to access federated services will involve re-authentication through that IDP. You won’t be using credentials to access those diverse services—the IDP will be sending them out. Same time savings as SSO, and similar risks if the IDP is breached.
For the user, federation may seem just like another form of SSO (squares and rectangles, again), but the architecture of each is actually very different. Both have their pros for the user, and their cons for the organization. Luckily, the right IAM solution should allow for a more frictionless user experience in either of these environments.
6. Zero Trust
Zero Trust may not sound like it should be a crucial part of an organization’s security posture in today’s cultural moment. The modern organization aspires to be flatter, more open, and full of collaboration—right? In that light, zero trust may sound a little punitive or harsh, but nothing could be further from the truth. In fact, a Zero Trust security model has absolutely nothing to do with the organization’s view of the user, or how users are treated within a network. Basically, it just holds devices up to the same standard that users have almost always been held to.
Read More CloseA Zero Trust model says that anything coming onto your network (person, or device) has to have a positive identity that’s verified by the system. Put simply, “Trust never, always verify.” That way, access is restricted to licit users and devices: trusted entities. When hundreds or even thousands of internet-enabled devices are able to come on the network of a large organization, it’s crucial to give them access rights commensurate with what they need from the network—which shouldn’t be much.
So how does a Zero Trust security posture contribute to a safer organization? Basically, it makes sure that what’s on your network belongs there and heads off breaches by unauthorized devices that may not be properly configured. It also addresses vulnerabilities arising from use of your network’s resources by devices that may be communicating remotely over an insecure internet connection. Finally, it keeps users from bringing in their own less-secure devices and inadvertently causing a breach. No one wants to be that guy. With a Zero Trust security model, they wouldn’t get the opportunity.
7. Phishing
Phishing is an exception to the rule on this list of misused terms, because it probably isn’t something any of you are misusing—per se. Rather, it’s a term that’s had a lot of other companion terms tacked onto it in response to an ever-changing threat landscape, and those companion terms are becoming increasingly more relevant as crooks become more sophisticated. Instead of going away, phishing is becoming more insidious.
Read More ClosePhishing, as you probably know, continues to be one of the most common security scams. Through email (the usual source), text, phone, or even messaging, social media, and productivity apps, crooks attempt to steal user data. Usually, they’ll pose as a legitimate organization and steal a bit of formatting from licit communications from those organizations. The goal is to get people to click a malicious URL, log in to a fake site, or download a virus-ridden attachment.
Because it can be devastatingly successful, cybercriminals have continued to innovate. They all want to build the better phish-trap, which is why there are some new terms associated with this old-school brand of attack:
Spear Phishing: Spear phishing is ultra-personalized, targeted at specific users. The communications will often include specific, seemingly hard-to-spoof information to make the user think that this is legitimate communication.
Whaling: Continuing the metaphor, whaling refers to the efforts of fraudsters to hack a high-level executive in an organization and steal their credentials. Once they’ve caught the “whale” they can perpetrate CEO fraud, sometimes called business email compromise (BEC), and use that high-ranking individual’s account to steal from lower-ranking individuals in the organization.
Clone Phishing: Clone phishing goes beyond spoofing the style of a legitimate email and outright clones an email that users may have seen many times before from a service provider. It will attempt to be indistinguishable from emails the user is familiar with (usually service-related). This one can be scarily difficult to spot.
8. Internet of Things
If you think of a certain talking home speaker system or your smart oven when you think of the Internet of Things (IoT), you’re not alone. Consumer “smart” devices overwhelm the public imagination when it comes to IoT. In reality, plenty of simple, “dumb” devices also populate the Internet of Things, as well as a host of devices that facilitate everyday life and undergrid critical infrastructure, including industrial controls for energy and manufacturing or transportation communication networks that facilitate self-driving vehicles. A better way of thinking about IoT is to consider the entire ecosystem of devices that access your organization’s network, whether smart, dumb, interface-rich, or interface-less. When you look there, IoT becomes a lot bigger—and a lot scarier, too.
Read More CloseThe surface area of this ecosystem and its vulnerability to breach is enormous. A “headless” device, which has no clear user interface and may even communicate through archaic or unsecured protocols, is an attractive target for crooks. What’s crucial is to have an identity and access management solution that encompasses all of these headless devices (Zero Trust), ensuring that their access to the network is licit, and that no bad actors are hijacking the device to access your network.
The consequences of an IoT breach can be dire, but avoiding breach isn’t necessarily simple or straightforward. A great illustration of this concept is the recent discovery that one popular smart light bulb sold on Amazon was essentially cracking network security wide open for many consumers without their knowledge. This bulb stored wi-fi credentials in plaintext in its firmware and had no security settings whatsoever.
Because these devices tend to utilize low-energy chipsets and low-complexity code (code that is sometimes downright archaic), they can be a welcome mat for hackers. Today’s IoT ecosystem is full of mismatched headless or limited UI devices that may be ticking time bombs.
Continue exploring topics in authentication with this related post: Multi-Factor Authentication and Single Sign-On Explained.
div { display: none; } .clicker span.less { display: none; } .clicker input[type="checkbox"]:checked ~ div { display: block; } .clicker input[type="checkbox"]:checked ~ label > span.more { display: none; } .clicker input[type="checkbox"]:checked ~ label > span.less { display: inline; } /*-->*/