Authentication Considerations: An Introduction
In Part 1 of this blog post series, we discussed the history of authentication, mostly centered around a username and password combination – which we consider to be “something you know”. Password managers provided a solution for generating strong passwords but did not address the concern of credential sharing or verifying that the user is the actual owner of the credentials. Passwords were still vulnerable to phishing, password dumps when a platform was breached, or advanced brute force attacks on systems that did not limit the authentication attempts. The next major transformation in the industry was multi-factor authentication (MFA). In this blog post, we are going to discuss some important security considerations for implementing MFA – which is considered to be “something you have”.
Smartphone Era
Authenticating with more than a username and password ensures that a user must possess an additional mechanism to gain access to a system or platform. The easiest way for the industry to rapidly adopt this new trend was to make use of tools or devices that users already possessed. At this point in time, most people own a smartphone, either for business or personal use, that they use daily. These smartphones function on a data connection that requires a SIM card that enables primary features such as calls and SMSs. Combining these technologies means that a user can receive an automated phone call or an SMS with a One Time Password (OTP) that they can then provide to a platform they are signing into, in addition to a traditional username and password combination. The introduction of OTPs enables systems to verify a user’s identity during every authentication that occurs.
One of the positive impacts of the implementation of MFA is that password-sharing practices have declined due to the cumbersome task of needing to obtain the OTP from the original user, who may or may not physically be in their vicinity. Therefore, people started to use their own credentials when authenticating because it was less effort. However, on the flip side, MFA can also be implemented incorrectly or not fully adopted. In particular, some concerns have arisen with OTP mechanisms where OTPs are predictable, can be used multiple times, or allow for infinite guesses which make a brute force attack possible. The clear text nature of the delivery mechanisms (SMSs and phone calls) for OTPs also became a security concern with malicious smartphone applications having the ability to intercept incoming messages or record calls. Even scenarios such as performing a SIM swap have potential implications on the security of systems that implement OTP mechanisms, as OTPs would be sent to the SIM swapped number. This presents an avenue of attack for malicious threat actors who had found a way to illegally perform SIM swaps.
Hardware Keys
“Something you have” doesn’t only apply to smartphones with the ability to receive OTPs but could also refer to hardware keys. A hardware key is a read-only secure digital key that is generated with software and stored on a hardware device. A digital key can be compared to a physical key that unlocks the front door of your house. To enter your house, you need a unique key that fits the lock and only the people that live in the house would have access to such a key. A digital key functions in the same way and serves as a secure authentication factor, especially when the key contains additional encryption. For example, when a hardware device is inserted into your computer via USB, a PIN may be required to unlock the device and access the digital key.
At the point of inception, hardware keys were not widely supported. Special software was required across the estate to support these keys. Additionally, not all administrators were proactively upskilling themselves in these new technologies. Through iterations of different hardware keys, researchers found zero days in the firmware which enabled an attacker to bypass some, or all, of the security mechanisms on these keys. This means that a key does not last forever, and you will need a new key every time your current key is deemed to be vulnerable with little to no possibility of a patch. Diving deeper, the algorithms that generate the key and encryption algorithms that protect the key periodically increase in size and complexity as time progresses, but older hardware may not always support larger or stronger keys.
Deploying hardware keys at scale is not seamless and requires a large amount of effort, especially in organisations with thousands of users. Keys are often lost or misplaced by users and the IT overhead costs can increase accordingly. Furthermore, manufacturers have a premium asking price for the most secure versions of keys, so budget might also play a big factor in determining the feasibility of its use. It can be an overwhelming amount of effort for an additional security mechanism, especially when compared to the ease of deploying an OTP mechanism.
Users seem to prefer the OTP mechanism for everyday use; however, hardware keys are a great practice for all system administrators, especially in server environments that don’t have access to the internet or don’t support OTP functionality.
Time-based One Time Passwords (TOTP)
The OTP mechanism has been improved with the introduction of Time-based One Time Passwords (TOTPs). While an OTP uses SMS or phone call to send you a code that the server has generated, TOTP uses a standardised algorithm that uses the current time as input to generate unique numeric passwords. These time-based passwords are also available offline, making their use quite appealing.
A common example of TOTP is when a user is presented with a QR activation code that is valid for a limited amount of time. This QR code is scanned by an authentication application such as Microsoft Authenticator, Duo, Authy, Google Authenticator, etc. The QR code contains a secret key that is added to the algorithm in addition to the current time. With modern apps, the password is generally refreshed every 30 seconds. When codes are entered incorrectly, websites or platforms will often force you to solve a CAPTCHA or puzzle to verify that you are human. This makes it difficult for an attacker to automate brute force attacks when trying to maliciously access an account.
TOTP has proven to be more secure than OTP or hardware keys. Today, MFA apps have evolved into powerful authentication tools with a lot of functionality. Apps offer push notifications which makes it a lot easier for users to authenticate. Automatic security patching and functionality updates are seamlessly available via the device’s app store. The application itself may be locked with a PIN code or biometric authentication, making it difficult for attackers to read your TOTP even if your device is unlocked. One of the greatest advantages of using an application is that the application can be managed, along with the device itself, as part of a corporate IT build. This gives an organisation greater control over the security of devices accessing corporate data.
With the use of authentication apps, the dependency completely shifts from SIM cards (which the OTP used) to the device that the application resides on. The shift away from SIM cards, including the clear text data that is being transmitted on them, provides a clear security advantage. In the 21st century, smartphones aren’t just independent devices that are assigned to a user. They function as part of a network or VPN and hold corporate data providing functionality somewhat equivalent to a corporate workstation.
Implementing Multi-Factor Authentication (MFA) – What You Need To Consider
The concept of Zero Trust fashions a “never trust, always verify” approach to the entire information lifecycle. The following are some key considerations for the configuration process:
MFA Providers
MFA is generally a cloud or private cloud-based technology that ties multiple devices together in the authentication process typically over one or more internet connections. Choosing an MFA provider for a corporate environment should be carefully considered. The provider needs to provide features to meet all current and future requirements. Ultimately, the MFA platform governs the security in the authentication process and on the devices that corporate data will reside. All organisations that make use of a particular provider will be vulnerable to any of their platform’s security vulnerabilities, and subsequently affected by the amount of time that their development team takes to remediate any such vulnerabilities.
Users And Devices
When configuring a user with MFA, to enter a state of compliance, the user or administrator is required to submit additional information related to the user and device that the application will reside on. This information may also be used as a recovery mechanism. All configured users must enter a compliant state to be able to securely perform MFA and access corporate resources. Users that are not compliant must be denied access.
All users in an organisation must be treated as equals. Administrators should not make any exceptions in relaxing MFA for any user or themselves as an attacker could use that to their advantage. All users must enroll and comply with the organisation’s MFA policies including any directors or managers. Granting exceptions or control of MFA outside the circle of IT administrators will increase the organisation’s attack surface.
The allowed number of devices eligible to register for MFA should be configured to align with the number of devices issued to the user. For example, if only one smartphone has been issued to a user, the number of remembered devices can be limited to one so that an attacker cannot register a second MFA device and perform any malicious MFAs.
It is important not to overlook guest accounts, temporary testing accounts and other service accounts when configuring MFA. Accounts where MFA is disabled such as service accounts must be secured via additional conditional access or security mechanisms. For example, a Teams Rooms device (which is communal inside an office) will not function properly with MFA enabled, as MFA requires the TOTP to be registered on a single user’s device. Considering the device will be fixed inside a particular meeting room, logons of the corporate account must be fully restricted to that specific device and that specific network in which the device will attempt its logon, including the network’s public static IP address.
Furthermore, additional conditional access and device compliance policies can be added to further restrict where and how users and devices can use MFA. There are several policies that should be considered to strengthen the MFA solution.
Authentication Apps
Any authentication application will be affected by vulnerabilities that may be discovered in the various authentication applications. It’s important that the application is forced to always be up to date and in a healthy state. Additional security mechanisms such as applying biometric or PIN locks when accessing the application is highly recommended.
Location Restrictions For Multi-Factor Authentication
MFA should be locked down to the countries in which the business operates or in the countries that employees reside in. This blocks connection attempts from unexpected locations.
Although the device and enrollment processes may be secure, the connection paths that the data traverses need to also be secured. Connecting a device to the corporate VPN or enforcing trusted locations enables the platform to allow MFA attempts to only originate from a specific location, such as the corporate network.
Modern MDMs and Authentication providers can detect when a connection is received from an untrusted VPN or Tor network. Practically, the network connections in your organisation will never need to travel through a public VPN or Tor network. Attackers generally use these avenues of the internet to mask their IP addresses and location so that they are untraceable. This also causes other issues because logging isn’t accurate which will have an impact on any potential cyber investigation. Therefore, it is safer to automatically block these kinds of connection attempts.
Security VS Productivity
From a user’s perspective, MFA is just another routine to adopt in their daily digital lives. But for organisations, there is a constant need to weigh up security and productivity in all process designs. When introducing MFA as a new routine, a balance needs to be found between security and productivity. For example, it is unproductive to MFA every single time a PC is locked or goes to sleep but authenticating once a day to a system may be more reasonable. Using single sign on and session-based MFA will also promote productivity where the user is required to sign into fewer systems.
It is recommended that session validity, however, should not exceed a working day to prevent the window of opportunity for an attacker from getting too large. When a user finishes at work for the day and access is no longer required, the MFA token should expire. If further access is required, then authentication should reoccur. If the authentication session is kept active for a lot longer, an attacker could exploit this to access systems after hours or when the user is on vacation.
Backups
As with any IT platform, it’s essential that backups are performed regularly and securely. There are different forms of MFA backup and deciding on the best practice will depend on the needs of the organisation. Cloud storage is a convenient way to back up authentication. Modern cloud platforms include more than just TOTP functionality, such as password managers, storing financial card information and data backups. They also sync across multiple devices, thus making it easier for the user to access their authentication data. While the functionality is advantageous, organisations are reliant on the security of the cloud platform to protect their data backups. Major breaches of databases containing users’ authentication data are not uncommon, even in the cloud space. In organisations where data integrity and security are critical, administrators will require a more secure way of backing up their authentication.
Backup codes are a good offline method for quick recovery or when a user is travelling in a different time zone to the IT team because users can generate their own backup codes. These codes can prove to be a security flaw if not stored in a proper manner. Storing them in a non-encrypted location means that an attacker may gain access to the codes and reset the MFA entirely. For example, if the codes are stored in cloud storage (i.e. OneDrive, Dropbox or iCloud) an attacker may already have access to those codes. This may be exacerbated by the fact that cloud accounts commonly act as a single sign on mechanism to many other accounts. Generally, storing backup codes in an encrypted password manager, separate to the MFA platform, is recommended.
The most secure method of recovery is having the organisation’s IT team reset accounts for users. Although an increase in IT overhead, this is a clever way to exercise backups because users will not have to store or remember anything. IT may physically or telephonically voice or video call to verify the user’s identity which creates an additional layer of verification. Having the recovery process be the responsibility of the IT team ensures that a compromised user account is not able to reset its own MFA.
Alerting And Monitoring
Alerting and monitoring is crucial in identifying any attack. The more information that administrators and incident investigators have available to them, the more effective they are in identifying, responding, and defending against that attack. Most modern MFA platforms can provide administrators with important information related to MFA attempt, such as the requestor’s account information, general location, IP address and device information. They are also able to alert on policy breaches and malicious attempts. Users are also able to report malicious MFA attempts. For example, if an MFA request is received and the user is on vacation or not using their corporate device, the user must easily be able to report it to the IT team immediately. Additionally, a high-level alert must be sent to the IT team if the user rejects the push notification. Ensuring that alerts are in place enables the IT and security teams to immediately begin investigating.
When it comes to any alerting and monitoring, it is important to practice an established and routine process that allows the correct information to be alerted and the appropriate follow-up actions to occur. Processes and steps within the processes must be detailed and easy to understand in a state of panic. Organisations are often overwhelmed when a breach occurs, and lack of communication and understanding of the process could prove to be detrimental.
Tiering
In the Zero Trust world, we classify users, systems and access based on a tier system. Tiers metaphorically are like layers on a wedding cake:
- Tier 2 represents user activities or systems
- Tier 1 represents server administrator activities or systems
- Tier 0 represents domain or global administrator activities and systems.
Adopting the tier system is an important practice to classify systems, users, and platforms. Users that use MFA must be configured and grouped separately from Tier 1 and Tier 0 users. Only the specified tier must be granted access, all other tiers must be configured separately. Exercising the tier system will containerise access, but more importantly containerise an attack. Generally, if tiers are crossed or mixed, an attacker will require much less effort to gain full control of an organisation and it will be more difficult to contain the breach.
As we exercise tiering, we must also tier MFA. MFA controls for Tier 1 and Tier 0 should be as strict as possible. Administrators should also have separate policies from all other users and systems, with no exception. This may mean that an administrator will have more MFA entries in their app for different tiers. For example, when establishing a connection to administer a server, the administrator might need to approve an MFA prompt every time the server is accessed. Relaxing this may grant the attacker access to the system without MFA. The goal is to create layers of security so that attackers fail in attempting to compromise any system.
Additionally, SSO should be set up based on tiers. For example, Microsoft Office, an HR platform, and a sales platform should have a different single sign on to an Azure console or AWS console. This mitigates the risk of a compromised user granting an indirect compromise to Tier 1 or Tier 0 systems.
Although an administrator of any given tier might have the access they need when granted, it’s important to add a requirement for peer or team lead approval during the authentication process. Access may be approved or pre-approved based on the tier and circumstance. For example, admin access may be pre-approved for Tier 2 or Tier 1 access during business hours, however, additional approval may be required after business hours. Another example may be when administrators try to request Tier 0. Adding in a human element to the verification strengthens the authentication process and IT change processes. This will deny a compromised administrator’s account from gaining Tier 0 level access without a valid request, approval, or verification. For example, on Azure, the global administrator should not be logging on daily. The configuration of Azure generally happens in the setup phase and subsequent changes that take place should be requested, documented, and approved. The global administrator role must be restricted to reduce the possibility of a full compromise. In this regard, Microsoft has implemented Azure PIM, with the easy ability to do additional approvals, to aid organisations when enforcing this practice.
What’s Next for Authentication?
As many organisations strive to secure their infrastructure and adopt this modern level of authentication, we must also prepare for the next step in the authentication journey. The industry is moving towards a password-less authentication model. In the final part of this blogpost series, we will be looking at some of the upcoming innovations in the authentication space, discussing how they are being adopted and what still needs to be done before they can be trusted as part of our corporate authentical models.
Further Concepts In Authentication
Just Enough Admin (JEA)
In the chain of authentication, it is imperative to exercise the Zero Trust concept. It is important to define control in terms of who can administer and control MFA. Admin accounts must be separated based on tiers. For example, helpdesk admin roles will have Tier 2 functionality such as the ability to deploy new users, reset passwords and grant basic access to companywide platforms for example, the company SharePoint. Access must not exceed Tier 2 functionality. Admins that require further access such as controlling conditional access policies or configuring MFA must have a different account or role. Containerising access will allow teams more time to defend against an attack. There may be an infinite number of roles but having an account for each role is not practical. Administrative access may be grouped into roles based on tiers. The most basic form is admins having different Tier 2, Tier 1 and Tier 0 accounts that is further limited to roles assigned to these accounts. Secure password managers make it effortless for admins to have multiple accounts.
Just In-Time (JIT) admin
When administrative access is not required, it should be turned off. Having always on administrative access means that an attacker could escalate privileges or take advantage at any given time. In simple terms, if there’s no active administrator access, then an attacker cannot use it to compromise an organization. Access should be requested and granted when required. For example, when a Tier 2 administrator receives no password reset requests for the day, Tier 2 administrative access should be disabled. When a password request is inevitably requested, the administrator may request access via a secured platform that verifies the identity of the admin which further requires MFA to accompany the request. Practically, password reset requests are common during the workday therefore the requested access may expire after a reasonable amount of time, such as 2 to 4 hours. Furthermore, the ability to request different tiers of access should be restricted to working hours only. Emergencies and planned changes out of business hours can be pre-scheduled or escalated to a senior admin or team lead that may grant access. Remote desktop protocol (RDP), Secure shell (SSH) or any administrative connections may also be governed by time restrictions during business hours and maintenance windows. We highly recommend adding MFA to these connections so that we may always verify when an administrator makes any connection.
