Architected with security in mind from the very beginning
Authentication token security
Security authentication tokens are recreated on every login. Each token will be tied to the TLS session ID of the connection. Since each application must negotiate its own session when it initiates a connection, the authentication token cannot be shared even among different applications or browsers on the same device. In the unlikely case that the authentication token is compromised, this measure severely limits its usefulness. Changes to enable this functionality are in process with our data services team.
In addition, authentication tokens are not available to browser scripts and can only be obtained by intercepting the HTTP connection stream.
In the unlikely event that your browser connection has an attacker secretly listening and altering communications, (otherwise known as a man-in-the-middle attack), the attacker would be unable to reuse the authentication cookie and unable to access your account.
Ability of malicious scripts to navigate the navigation
The application makes heavy use of the web components ShadowDOM specification. Because of our implementation, application content is not part of the standard DOM tree. Injected scripts (typically seen via malware or rogue add-ons) cannot access the content through the standard means.
Currently there exist methods to traverse the ShadowDOM. However, the newest version of the specification enables a “closed” ShadowDOM which blocks this type of traversal. As soon as browser support for the specification exists, we plan on utilizing this feature to further increase the difficulty of traversing the DOM to harvest user data.
This feature will only be available to ShadowDOM enabled browsers. This will exclude Internet Explorer. All other browsers are actively working on support.
This protection makes it much more difficult for browser add-ons and malware to extract information from your web browser screen (also known as screen scraping).
Content security policy
In the event that a malicious script (typically seen via malware or rogue add-ons) manages to obtain user data within the browser, the content security policy limits the domains to which the data can be sent. Compliant browsers detect outgoing connections and only allow them to a predetermined whitelist. In addition, attempted violations to this policy can be reported back for analysis.
Internet Explorer does not (and will not) support content security policy. Microsoft Edge and all of our other supported browsers already support this specification.
The content security policy provides additional limits on what the application is permitted to do. In the unlikely event that a malicious script was injected into the page, this policy prevents the script from sending your data to a third-party. This ensures that your data stays where it belongs, in our protected and predetermined whitelist environments.
Browser session timeout
For the security of our users, we implement a browser session timeout lasting 10 minutes. After 9 minutes of inactivity, we display an alert with a 60 second countdown prompting the user to click anywhere in the window to acknowledge that they’re still actively browsing. If they fail to do so and the session times out, we sign the user out, destroy their local data, and take them back to the sign in view.