What You Will Learn
- Authentication and authorization defined
- How AuthN and AuthZ continue to evolve toward Zero Trust cybersecurity postures
- The value of passwordless MFA
AuthN vs. AuthZ
People often confuse the terms AuthZ (authorization) and AuthN (authentication). Some of this confusion stems from the fact that the short forms of authentication and authorization both start with “auth.” Even a delegated authorization scheme like OAUTH can be easily confused with something that has to do with authentication.
In reality, the terms refer to two simple and complementary concepts that work in tandem to protect identity and access to resources. Authentication or AuthN is the process of proving that users are who they claim to be. In other words, proving that the user behind the keyboard owns the account associated with the username.
Authorization or AuthZ refers to permissions, specifying which resources an authenticated user can access and what operations they can perform on or with that resource. For example:
- Can a user access the HR folder on the company file server?
- Which files in the folder can they access?
- Can they read and write to it or is their access “read-only”?
Authentication and authorization follow a natural order
Users authenticate first to establish that they do in fact own the username account. Once their identity gets verified, their access management permissions to resources – their authorizations – get looked up in the authorization system and enforced.
Authorization schemes historically defined user permissions based on roles assigned to the user’s identity. Under a role-based permissions scheme, each user account gets assigned a role definition, and permissions associated with that role. For example, a user with an admin role obtains extensive permissions to read and write to all resources, whereas a user with a contractor role may only access and read a small subset of applications and databases.
But more modern authorization approaches implement a more granular approach that looks at what specific capability or data the user wishes to access, and contextual information associated with the network access request.
AuthN and AuthZ work in tandem
Together, AuthN and AuthZ prevent unauthorized access to data and systems. In the most basic setup, users authenticate once, typically when logging into the company network, and their authorizations/access permissions get determined based on the role associated with their user credentials.
For example, a user authenticates while logging on to their Windows desktop and their authorizations get determined by the group to which their user account belongs – e.g. system administrator, finance employees, developers, etc. In a modern setup, users authenticate more frequently, and authorizations get defined at a more granular level.
In some cases, authorizations become contingent on various contextual parameters. For example, users may need to authenticate every time they request access to a resource, and authorization may be granted for accessing and performing specific operations on a specific resource. IT can further limit authorizations according to where and how users connect, the security posture of their devices, and their previous history.
What gets secured by AuthN and AuthZ?
The concepts of authentication and authorization apply to human users as well as unattended software and systems interacting with one another without human intervention (e.g. one application asking for services from another software via an API interface).
Recent Developments in AuthN and AuthZ
More recently, the idea of “continuous authorization” has become popular and involves continually permitting access to resources based on the integrity of the user device or continuous authentication of identity. With this approach, users are evaluated not just at the start of a session with a resource but at a periodic interval of time.
In this scenario, AuthN stays highly connected to AuthZ since a failure of identity during a more continuous check would imply an action needs to be taken immediately on the AuthZ side. In the past, the system might place a user on a specific VLAN with less privileges and access. Now, specific application workloads or services may be designated ‘off limits,’ or a user blocked from accessing an application altogether.
Unlike AuthN, authorization underwent more dynamism and change in the past 15 to 20 years, starting with common ways to authenticate users:
- Passwords served as the default for authenticating users for ages. The user enters a username or user id that tells the system who the user claims to be, and a password, a shared secret only the “real” user and the authenticating software should know. If the user recalls and provides the right password, the authentication service assumes they are who they say they are.
- Two- and multifactor authentication (2FA/MFA). As passwords became increasingly vulnerable to stealing and other attacks (primarily via phishing), companies rolled out multifactor authentication (MFA) on top of the standard UN/PW combinations requiring additional factors for stronger, higher-assurance authentication.
The first authentication factor typically remains the password, but in addition users must demonstrate possession of a physical authenticator (something the user has) or produce a biometric or behavioral print (something the user is). A common second-factor authenticator is proving possession of a registered hardware authentication token (i.e. OTP token or USB key) or device (i.e. mobile phone that receives a call or text). Proof of possession is generally done using one-time passcode (OTP) technology or public-key cryptography (PKI certificates).
- Biometric authentication has seen a dramatic increase in use, whether as part of an MFA scheme or as a standalone authentication method. Many biometric signatures are in use today, the most popular being fingerprint and facial signatures. Biometric prints can be obtained from a fingerprint sensor embedded in most mobile devices and laptops, face image can be taken from the device camera, or voice-print captured by its microphone.
Behavioral biometrics also uniquely identify a user by measuring the distinctive way in which a user strokes the keyboard (keystroke dynamics) or the unique patterns used to draw a signature.
Passwordless Authentication is the Future
The adoption of passwordless authentication systems is driven by the realization that password vulnerabilities are at the heart of a great majority of network security breaches. Passwords at the hands of users easily get compromised via various flavors of phishing attacks, or simply guessed by sophisticated attackers. Passwordless authentication offers a superior alternative to passwords that delivers better security and a better user experience (UX) at lower cost with less work for IT.
As its name suggests, a passwordless MFA solution removes vulnerable passwords that play a role in more than 80% of breaches and replaces them with one or more (typically at least two) alternative forms of authentication. For example, a registered mobile device in combination with a fingerprint taken from the device’s sensor. Other forms of passwordless authentication include registered mobile devices in combination with a faceprint or voiceprint, a dedicated USB authentication token device, etc.
Passwordless Authentication and Zero Trust
Zero Trust acknowledges that authenticating users at the front gate – the network perimeter – and authorizing them to roam free and access anything and everything once they’ve crossed the perimeter no longer works. Instead, Zero Trust requires users to authenticate more frequently and authorizes them to grant access to resources on an as-needed basis.
More granular permissions schemes align with Zero Trust and a “never trust, always verify” approach. For example, a user with access to the salaries folder owned by the HR department may only be able to see the salaries of his direct subordinates, and only when logging in from a company–issued computer during work hours.
Passwordless authentication and Zero Trust continue to be major investment areas for companies facing modern threats, high insurance premiums and stringent regulatory mandates.
Pro Tip: What MFA should I use for my business
There is a saying that enterprises only do things for three reasons: (1) to make money, (2) to save money, (3) because someone said they had to. The third alludes to compliance and regulations. MFA decisions are no different, but what is the right MFA for your business?
The best approach to any security problem is to consider risks and consequences and then apply the appropriate controls—not too much, not too little. The same goes for choosing the right MFA for your business.
Security standards like CIS and PCI DSS call out MFA without specifying the quality or characteristics required. However, the NIST 800-63, Digital Identity Guidelines, provides invaluable insight into choosing the right MFA for your business. While you may initially feel that NIST is not for you, it’s important to note that 800-63 flows into 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, which applies to enterprises in direct and indirect contact with government entities. This document is considered an industry best practice worldwide, making it a crucial resource for MFA selection.
800-171 asks you to consider the impact of an authentication failure against six categories (reputation, loss, public interests, data loss, safety, and the law) upon all stakeholders in your business. Based on your low, medium, or high response, apply the appropriate assurance level to those workflows. Depending on your industry, even a medium risk on safety may push you into AAL3.
The interesting part of high assurance AAL3, passwordless MFA, is that it fulfills all three elements of a business decision:
- It makes money through user and admin productive gains.
- It saves money by eliminating password overhead tasks.
- It meets the most demanding compliance requirements.
Read the eBook to learn how: Users Love Passwordless MFA But IT is the Real Winner