How does Robot handle Multi-Factor Authentication?
UiPath Robots: Guidance for Handling Multi-Factor Authentication
Multi-Factor Authentication often referred to as MFA, refers to a security measure put in place that requires more than one type of authentication in order to be authenticated. Most commonly, MFA is broken up into three types: something you know, something you have, and something you are. A security system may require any combination of these authenticators or multiple instances of the same factor. Often referred to as out of band authentications, the more secure implementations of MFA also require that these authentications are performed via different devices or different protocols.
There are many advantages to leveraging multiple factors of authentication. Credentials are much harder to steal, making it much more difficult for an attacker to impersonate a legitimate user. This is especially true of authentications done out of band as it requires an attacker to compromise more than just the user’s computer. There is greater assurance that the user authenticating is in fact the user who should have access. Passwords combined with other factors of authentication do not need to be as complex, as long, or changed as frequently to achieve the same level of assurance compared to when they are used by themselves.
Many of these same advantages pose a challenge for Robotic Process Automation as MFA is designed in part to prevent an attacker from being able to impersonate a user via code. To that end, there are a number of strategies or options that can be leveraged to address MFA when using UiPath Robots.
Options for all MFA Types
- Option 1, Attended Robots:
One option for all RPA implementations is to use attended Robots for automation. The Robot pauses its work when an authentication must be performed, allowing the user to perform that function, and continuing the process later. The downside of this is that attended Robots are inherently less efficient than Unattended Robots as they can only be executed when the user triggers them. This also means that the Robot requires human supervision and is unable to run behind a locked screen.
- Option 2, Single - Factor Authentication:
In certain cases, the option to reduce the requirement for authentication to only be a single-factor is an option. The downside is that a less secure entry point is created. Often mitigating factors can be added such as IP filters, extremely long passwords, or even building regular password changes into the automation workflow. While a human may have difficulty remembering a 100 character long password that changes every minute, a robot does not. Starting in 2019.10, UiPath is offering a pluggable credential vault system for credentials stored in Orchestrator. This allows customers to use a wide variety of privileged access managers to automate password rotation and governance.
- Option 3, bypass via an API call or admin access:
Most MFA systems offer a way to issue a token that can be used in place of the actual authentication mechanism. Vendors frequently refer to this as a bypass token or a static token. Normally this mechanism is used by an administrator to allow users who have lost their physical device for receiving an MFA code to login temporarily. Robots can leverage the same mechanism to create a just-in-time (JIT) authentication scheme where a Robot creates a code and then the same Robot or a separate Robot leverages the code to login. Ideally, this can be implemented out of the band of the actual robot performing the login to maintain separation of powers.
Knowledge-Based Security Questions are predefined questions and answer sets that can be asked in addition to username and password. They can be predefined questions such as “What is your mother’s maiden name?” or “What was the make and model of your first car?”. They can also come as free - form questions that the user enters.
- Option: The easiest way to handle these types of questions is to treat them the same as username and password credentials where the username is the question and the password is the answer. SMS-Based Authentication is where a security system sends a random code, often numeric, to a cellular phone where the code must be retrieved and entered by a user.
- Option: There are a wide number of VOIP systems that can be accessed via a browser or installed application. This allows the robot to obtain the code via a get text activity and enter it in order to complete the authentication. The speed of delivery can sometimes be an issue with this scenario as SMS delivery, especially to VOIP can be variable. To avoid re-use or phishing, these tokens expire after a certain period, so if the Robot cannot retrieve the token and enter it in time, the authentication has to be restarted. Interactive Voice Recording (IVR) Authentication is where an automated recording calls a user and speaks a random code to them that must then be entered to authenticate
- Option: Similar to handling SMS-based authentication, there are a wide number of VOIP systems that can be accessed via a browser or installed application. Many of these include a visual voicemail feature, enabling the code to be retrieved and entered. Accuracy of Visual VoiceMail can sometimes be an issue for this option, causing the bot to enter the wrong code.
Physical Random-Number Token Authentication comes in a wide variety of options. They are generally small devices that have a calculator type screen that can fit on a keychain. The most common of which is RSA SecurID or Oauth based tokens that have a number, usually 6 digits, that changes on a regular schedule, usually 1 minute or less. Users are asked to enter the number or code displayed. Sometimes a Personal Identification Number or PIN is required in addition to that code such as with RSA.
- Option 1 (Partial / Full Solution): Leverage a virtual token, sometimes referred to as a soft token, rather than a physical one. Almost every vendor that sells a physical token also sells a virtual version that can be installed as an application on a computer. The Virtual token will display the code after entering some form of authentication, generally a PIN. A Robot can use a get text activity to copy the code as it would do for any other application. Not every company has both physical and virtual offerings. As well, many of these vendors require separate licenses for the two different options. Specifically for Okta, Microsoft, and Google tokens, UiPath offers activities to allow robots to leverage these software tokens. See in UiPath MarketPlace .
- Option 2 (Partial Solution): Generate a list of one time use or time-sensitive codes out of band of the authentication. Most token vendors provide a mechanism to allow administrators to provide static codes to users in lieu of them using the code provided by the physical token. This is to allow a user a way to login in case they lost their token and are unable to get a new one right away. Often times, a list of codes can be generated for use as each code can only be used once. In this scenario, an administrator or a separate robotic process generates a list of codes and enters them as a queue in the orchestrator for the robot logging into leverage. This could all be done by a single process, but it is generally preferred from a strictly security perspective to have a separation of powers between processes. Employing this option requires that there is access to the system issuing the codes which is often a problem if the customer is working with a third party application. Additionally, codes must be replenished at the same rate at which they are used.
Smart Card Authentication is a way to issue users a certificate and keypair securely so that they can perform authentication via Public Key Infrastructure (PKI). Smart Cards can be physical cards that have a chip that is read by a computer. They can also be virtual where the information is installed as part of an application or in a protected chip such as a Trusted Platform Module (TPM) or a Hardware Security Module (HSM). Whether virtual or physical, the authentication process is essentially the same. The user enters a Personal Identification Number (PIN) that provides access to the private key portion of the certificate / key-pair. The certificate is then presented as part of a mutual-TLS authentication. Organizations that typically issue only physical Smart Cards, likely have a virtual offering for devices such as Smart Phones or Tablets where physical cards are not feasible, but heavy involvement with the security team will be required to leverage these as they are not standard.
- Option 1: ***This option requires a virtual smart card installed on the machine or a physical smart card issued to the Robot, where the Robot is installed on a machine with a smart card reader. Additionally, both Robot and Orchestrator must be version 2018.4 or later***. Orchestrator web.config is configured to allow smart card authentication. When the Robot is created or configured in Orchestrator, check the box for Smart Card Pin and store the PIN there rather than entering the username and password. The Robot can leverage this PIN for initial login as it would username and password. The Robot can also use the get credential activity if the PIN is needed for additional logins.
- Option 2 (Partial Solution): If the Robots are required to be installed on virtual machines and the smart card private key must still be installed on a hardware chip, not software, then a Hardware Security Module or HSM can be deployed as a partial solution. This option cannot be used today to have the robot perform the remote console or remote desktop login but can be leveraged for logging into applications or websites. In this solution, the private key is stored in an HSM and the robot accesses the PIN via a type of API call referred to as a PKCS#11 connection. The PIN, URL, and other connection information are stored as assets in Orchestrator.
Recommendations and Factors to Consider