Summary
The enforcement of two-step verification by Exact Online starting May 25, 2018 is a big step by a major player in the online ERP market towards achieving strong authentication to protect your and your customer’s data both for confidentiality as well as for integrity. Especially interactive use can be secured better in line with the confidential nature of the data managed at the cost of once per week entering a new 6-digit code.
Nonetheless, when some of your interactive users are unwilling, they can easily compromise the security of Exact Online as a whole for your company. In that case, the second level of defense is your authorization matrix.
Security imposed on 3rd party applications will hardly improve, so avoid the use of applications unless absolutely deemed necessary.
This note presents a number of recommendations to harden the security of applications for use with Exact Online.
Two-step Verification and Strong Authentication
Exact Online will, combined with GDPR becoming effective, require all users to use two-step verification for interactive sessions starting May 25. Two-step verification can be used to achieve strong authentication. Also two-step verification when correctly implemented can also achieve multi-factor authentication. Exact is the first essential players in the online ERP business to enforce this, which is a great step forward. Strong authentication has been the benchmark for information security in the Netherlands since decades for non-reversible financial transactions and personal data. Strong authentication requires implementation of at least two of:
- Location, such as a fixed IP address or physical address.
- Knowledge, such as password or PIN-code.
- Possession, such as device or token.
However, two-step verification does not guarantee strong authentication nor does it guarantee multi-factor authentication. You need to apply good care and carefully instruct your users to achieve strong authentication:
Strong authentication requires strong user mentality
Stated otherwise: when some of your users are unwilling, they can easily compromise the security of Exact Online as a whole for your company. In that case, the second level of defence is your authorization matrix: what can a compromised user do in terms of harm with your data both in terms of Confidentiality as well as Integrity. That defence line can be extended by the amount of harm you are willing to apply to unwilling users (just kidding).
The authorization matrix of Exact Online is applied on each and every request for data for both interactive as well as API use. Exact Online currently has no support for “scopes”, allowing more fine-grained access control per application.
This note provides some recommendations to harden security of Exact Online, especially in the authentication of 3rd party applications. It is however neither intended nor planned as an overview of all possible attack vectors that can be closed down by hardening. The note largely focuses on technology, leaving out largely the human-based risks such as social engineering. Please consult your local security officer for risk assessment, recommendations and exemptions.
Note that two-step verification currently only applies to interactive sessions. Typical non-interactive use is the use of certified and non-certified applications. Applications have various means to exchange data with Exact Online. The OAuth protocol used defines various scenarios (“flows”) for these, of which some are implemented in the Exact Online API platform. We will restrict ourselves in this note to the popular Code Grant Flow and Implicit Grant.
OAuth Code Grant Flow
General Recommendations
The Code Grant Flow uses a client ID and client secret as a kind of user name and password for an application to authenticate itself. The Code Grant Flow is intended for use in environments trusted by the owner of the application, such as their web server. It is not intended for use on environments not under control of the owner of the application, such as user devices (laptop, phone, PC) or servers, since the client secret can easily be compromised.
On first use the Code Grant Flow will generate a so-called “refresh token”, which is a kind of user-specific password associated with the application.
During the generation, the user authenticates itself, followed by authentication of the application. Between these two steps, a temporarily valid Authentication Code is made available during which lifetime the application must authenticate itself to get a refresh token.
The generation of the refresh token requires only two-step verification at the generation process. The resulting refresh token has an extensive lifetime, typically for eternity, without the need for two-step verification during that lifetime. After the generation process, the refresh token can be saved (preferably in a strongly authenticated and secure way) as non-strong authentication code and used to generate short-lived so-called “access tokens” till the user withdraws the application access from within the Exact Online Security Center (click on user name top-right, My Exact Online, Security Center).
In the Exact Online Security Center, you can also enable a mail message being sent when you log on from a previously unregistered IP address (default is to send no mail) and disable Google Analytics registrations (default is to register your Exact Online activity with Google Analytics):
Recommendation 1: in the Exact Online Security Centre enable mail on new IP address.
Recommendation 2: disable Google Analytics registration in the Exact Online Security Centre.
According to Je’kob “safest sex is no sex at all” and similarly the safest use of applications is no applications at all:
Recommendation 3: weigh the possible advantages and disadvantages of the use of an application. Avoid use of 3rd party applications not listed in the Exact Online App Store and applications provided by suppliers not in your jurisdiction.
Recommendation 4: as an application developer never use the Code Grant Flow to run applications on the device of an end user, such as using an iPhone or server app.
Recommendation 5: create a client ID per legal owner controlling the environment when you have to use the Code Grant Flow to run applications in an untrusted environment. This avoids attack vectors by one party impersonating an app, targeting another party which previously authenticated that app.
Note that the client ID is considered public information. Security checks based in any way solely on public information such as client ID are inherently insecure.
Since the use of the Code Grant Flow does not ensure strong authentication after initial creation, it is strongly recommended to apply additional measures:
Recommendation 6: create a separate Exact Online user account per connected app, so it is possible to extract from the audit information what application caused a change or retrieved data. Although solely a reactive measure, it enables better analysis of an actual or assumed security incident. This holds for all authentication scenarios.
Recommendation 7: regularly audit which applications have been granted access by your user community and apply preventive measures such as requiring users to have an internal form signed beforehand. It is currently not possible to centrally restrict the applications in use such as on Office 365, but this measure reduces the risk of applications not sanctioned by the management being accessible for an extended period of time. As an alternative consider use of an application-level firewall.
Also, once an application (as identified by client ID) has been authorized by an end user to access their data, recommendation 7 largely avoids scenarios in which an end user already logged into to Exact Online fully transparently allows access to Exact Online by an app. The following recommendation also reduces this risk:
Recommendation 8: Somewhat resembling the “Facebook pixel”, this risk can also be avoided by ensuring that users run Exact Online and Exact Online only on dedicated environments such as a separate terminal server.
Invantive and Code Grant Flow
The Code Grant Flow was only available on the Online SQL Editor and Invantive Producer Web applications of Invantive, since these run on Invantive controlled servers. Most Invantive products typically run on environments not under control by Invantive. Using client IDs per legal owner, we have implemented recommendation 5. We also require users to acknowledge they are aware of the fact that the Code Grant Flow with refresh token allows non-strong authentication for applications (see https://cloud.invantive.com).
To use the Code Grant Flow you can choose a database with at least one Exact Online data container as shown below. Instead of entering user/password, you can fill out the client ID, client secret, refresh token and redirect URI. This holds for all Windows, command line and web products:
OAuth Implicit Grant Flow
The Implicit Grant Flow is designed for use in interactive environments not trusted by the supplier of the application. For instance, Implicit Grant can be used to grant applications access to your Exact Online data through your browser using JavaScript. A temporary valid so-called “access token” is used to get access to the protected resources from code executed on the user’s device.
In such a scenario there are at least four parties involved:
- the user controlling the browser;
- the supplier providing the environment (Google for instance for Google Chrome or the SQL tool “Invantive Query Tool”);
- the resources to be authenticated for (Exact Online);
- the application and the web server presenting it.
The Implicit Grant Flow resembles the Code Grant Flow, but the application is by design not authenticated. Instead, the browser navigates through the redirect URI, which in it’s own right also has some security risks. Nonetheless, the client ID identifying the application can be presented to the resources for informational purposes. Note again that the client ID is considered public information and that it should never be used to control access; it is easy to determine the client ID of almost any app.
The end user controlling the environment (the browser and application) will have to establish whether they trust the supplier of the browser and the application to access their data. However, the access token returned by the Implicit Grant Flow has a restricted lifetime to reduce the risk of uncontrolled use of the token in the future. This lifetime on Exact Online is ten minutes.
For reactive purposes, you can apply the following recommendations:
Recommendation 9: create a separate Exact Online user account per connected app, so it is possible to extract from the audit information what application caused a change or retrieved data. Although solely a reactive measure, it enables better analysis of an actual or assumed security incident. This holds for all authentication scenarios.
Recommendation 10: regularly audit which applications have been granted access by your user community and apply preventive measures such as requiring users to have a form signed beforehand. It is currently not possible to centrally restrict the applications in use such as on Office 365, but this measure reduce the risk of applications not sanctioned by the management being accessible for an extended period of time. As a preventive alternative consider use of an application-level firewall.
However, since the (possibly untrusted) code is executing on the devices under control by the organization of the end user, you can also apply additional preventive measures:
Recommendation 11: enforce that users only run browsers that are considered trustworthy.
Recommendation 12: enforce users to run only client programs (such as Invantive Control for Excel) that are considered trustworthy.
Recommendation 13: enforce users to only access trusted websites containing code using Implicit Grant Flow.
Recommendation 14: as described previously the risk of the “Facebook pixel” can also be avoided by ensuring that users run Exact Online and Exact Online only on dedicated environments such as a separate terminal server.
Invantive and Implicit Grant Flow
All interactive Invantive products have supported and used the implicit grant flow since years.
Interactive applications such as Invantive Query Tool allow you to enter the user name and password on login in an application-specific browser window. A new access token is acquired for another ten minutes when the access token expires and resource access is needed.
Server applications such as the command line tool Invantive Data Hub exchange HTTP-messages directly with Exact Online, exchanging the user name and password presented to the application in device-bound encryption format as command line arguments or stored encrypted in the central database directory settings.xml or Invantive Keychain.
With the introduction of two-step verification on Exact Online, the user also needs to present a code of six digits that changes every 30 seconds, based on a string (the so-called “secret”) and the current UTC time. For more details please consult RFC 6238.
For interactive applications the user can enter the six-digit code interactively in the Invantive browser window. As an alternative, the user can save or memorize the secret string in a trusted environment. Since the secret string in general does not change, the user can also present the secret in an additional field called “Two-step Secret” . The six-digit code to log on is calculated from the contents of this field:
Using the Two-step Secret completely removes the advantages of two-step verification towards achieving strong authentication. We do not recommend to use the Two-Step Secret to log on unless made necessary by reasons outweighing the disadvantages and unless counterbalanced by additional security measures. However, it poses no extra security risks, since the following still holds and has been illustrated in examples above:
Strong authentication requires strong user mentality
For interactive applications we recommend to log on using user name and password, complemented by entering the six-digit code on every login.
For server applications the Two-step Secret can also be used. In general for server applications we recommend the use of the Code Grant Flow in combination with device-bound encryption of the refresh token and device-owner specific client ID and client secret.