Security in NoMAD Pro
With NoMAD Pro integrating a number of security tools, it’s important to understand how NoMAD Pro interacts with them and what you, as an admin, need to be aware of.
Currently NoMAD Pro works with Okta as an IdP and allows for your Okta password to be synched to your local account on the Mac. This is done entirely through Okta’s Authentication API. As such there’s no need for a client API key or really anything. The Authentication API should already be available on your Okta instance and as such, no Okta configuration is needed for NoMAD Pro to function. All API calls are done over HTTPS to just your Okta authentication endpoint. No HTTP connections are allowed, nor would your Okta endpoint accept them. Your Okta endpoint is the only URL that NoMAD Pro will connect with. While we may add a cloud licensing service in the future, at this point in time there is no “phone home” or other outbound connections made by NoMAD Pro. We may also add a crash and usage analytics service in the future, but this will be entirely opt-in if it’s ever instituted.
As part of the authentication operation, Okta will issue a session token, which is a one-time use token that can be used to bootstrap a session within a web browser. NoMAD Pro does not keep or inspect this token, instead it opens up the user’s browser of choice with a URL using this session token that will initiate a long-term Okta session within the browser. NoMAD Pro does not interact, nor could it, with any token or cookie cache within a browser on the local system. This is why NoMAD Pro has no understanding of if a user is already signed in with a browser.
NoMAD Pro can be configured to save the user’s Okta password in the user’s Keychain. We use the standard Apple SecKeychain APIs to do this so that the password is always stored in an encrypted format. NoMAD Pro will never store your password anywhere else. When using the password for any operations it is only stored in memory and the object is then scrubbed as soon as it’s not needed. When configured to synchronize the local password NoMAD Pro uses Apple’s OpenDirectory APIs to manage the password update for the local account.
NoMAD Pro has browser extensions for Safari, Chrome and Firefox. Each extension behaves slightly differently. All extensions will only have permission to inspect traffic going to Okta URLs ending with “okta.com”, “okta-emea.com”, and “okta-preview.com”.
Safari – The Safari extension is bundled as an app extension within NoMAD Pro itself. Once the application is copied to the local machine, the extension can be enabled within Safari. There is no way to programmatically or administratively do this as that is prohibited by macOS. Once enabled in Safari, all communication between the extension and the main application is handled by Apple’s app extension APIs. Both the application and the app extension are signed by the same Apple Developer certificate with the team ID of “VRPY9KHGX6”.
Chrome – The NoMAD Pro extension can be found in the Chrome Web Store. It works with a native messaging handler which is included in the NoMAD Pro disk image. The Chrome extension follows all best practices established by Google for Chrome extensions. The extension uses native messaging to alert the native messaging handler that the user needs an Okta session token. The native messaging handler then uses a native distributed notification to NoMAD Pro to show the sign in window. A successful sign in will generate a one-time use token that will then be passed back to the native messaging handler which will in turn pass it back to Chrome using the native message handling APIs.
Firefox – The Firefox extension behaves very similarly to the Chrome extension. It is available on request.
Active Directory Integration
If requested NoMAD Pro can get Kerberos tickets using the users’s password stored in the local Keychain. This is done via a Kerberos operation using the built-in Kerberos APIs. The passwords are never echoed out to a shell process or other external operation. Additionally the passwords are only kept in memory and are scrubbed from memory when no longer required. All LDAP lookups are then done using the Kerberos ticket, no other LDAP authentication is performed.
NoMAD Pro will read a user’s record in Okta, and additionally Active Directory if configured to do so, however, this data does not leave the local machine. NoMAD Pro does not send any information, PII or otherwise, to any service. Only the minimum information required to authenticate to Okta , and to AD if configured, is ever sent. Orchard & Grove, the developers behind NoMAD Pro, have no cloud services, console or other hosted service. So, if we’ve not made this painfully clear already, NoMAD Pro doesn’t do anything with your data or send it anywhere you don’t want it to go.
NoMAD Pro has been reviewed by outside security vendors and has also been penetration tested and fuzzed as part of this process. These reviews were funded by customers and so we’re not at liberty to disclose any specific results of those reviews, other than to saw that any issues found have been corrected. If you would like to do your own security review of NoMAD Pro, please let us know as we’d be happy to discuss what has already been done and what you’d like to accomplish. On request, and with proper accommodations, source code is available for review as well.
We take security very seriously and we welcome the opportunity to discuss our methods and to make our code better.