Cloud Specifications
      Back to home
      1. Help Centre
      2. Technical & Security
      3. Cloud Specifications

      Authentication and Authorization

      The mechanisms that are supported by FMI for authentication, password policies, and authorization.

      This article is for IT and security professionals

      The FMI Works product supports two different mechanisms for authentication depending on your service.  This is either the built-in FMI Authentication or your own Single-Sign-On (SSO) authentication.  Note: not all plans include SSO as an option.

      FMI Authentication

      The core FMI Authentication solution is built around two enabling systems and inherits their capabilities.  This follows the security maxim of using known solutions where possible.  

      Core authentication and authorization is provided from Microsoft's ASP.NET Identity solution.  

      Password Strength

      FMI password strength is enforced through three mechanisms:

      • Must have at least 5 uniquely different characters.
      • General password complexity, requiring either a variety of character types or very long passwords.
      • Penalties for using any "bad" password stem words

      Together this mechanism prohibits 100% of the top 100 most common passwords, and most of the 10,000 most common passwords.  

      When using uppercase, lowercase, numeric, and punctation types, users are required to use at least 9 characters.  If using just lowercase letters, then users must enter a minimum of 12 characters.

      Password "Storage"

      Passwords are not stored in the system, encrypted or otherwise.  Passwords checks are done through a one-way salted cryptographic hash. The algorithm uses PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations. 

      Password Rotations

      FMI recognizes that the best-practices for password history and periodically forced changes are in a state of flux.  The historic best-practice of forcing password changes has been found to encourage users to compensate by adopting weaker passwords.  Therefore, the current National Institute of Standards and Technology (NIST) guidelines state that forced password changes are discouraged (see NIST Special Publication 800-63B).   This advice is not yet universally adopted.  For example, OWASP follows this guidance in their Application Verification Security Standard (ASVS) (see ASVS v4.0.3-2.1.10), but has not yet adopted it in their OWASP Secure Coding Practices Checklist.

      FMI is currently compliant with NIST and ASVS recommendations.  For clients requiring more control over their password polices, FMI recommends using SSO; enabling clients to determine their own password rules.

      Additional Authentication Rules

      • Multiple attempts to login with a single username is throttled at the server, each additional failed request forces the user to wait longer, scaling up to 1 minute waits at 5 failed attempts.
        • At 5th failed attempt, account is completely locked for 60 minutes.
      • Multiple attempts to login from a single location is throttled at the server, each additional failed request forces all users from that location to wait longer, with different lengths based on the number of users that could be legitimately failing:
        • IPV4 determined location scales to 1 minute waits at 25 failed attempts,
        • IPV6 determined location scales to 1 minute waits at 300 failed attempts.
      • Password resets are achieved through a one-time, time-limited password reset e-mail.
      • First time user accounts are registered 'passwordless' with an invitation sent to their e-mail, upon accepting the invitation they are then sent through the password reset process.

      Multi-Factor Authentication

      MFA is supported as an option for users.  When used, FMI Authentication uses the standards RFC6238 TOTP protocol.  This is supported by Google Authenticator and Microsoft Authenticator apps and is registered using an on-screen QR Code familiar to users.  

      Single Sign-On (SSO) Authentication

      For enterprises that want to bring their own authentication mechanism, FMI Works supports the OpenID Connect exchange for SSO.  At present FMI has tested and supports Microsoft O365 and Okta SSO providers.

      When using SSO, it is typically not possible for all your system users to be able to use SSO.  While your internal staff will have a domain name that can be registered for your SSO system, FMI Works enables collaboration with third-parties such as a suppliers.  If you're extending invitations to users outside of your domains, these users will use the standard FMI Authentication.

      Authorization

      Authorization is stored and managed by the FMI Works solution using claims based policies.  These claims are stored with the client as either an HTTP Only cookie or JWT Bearer token (depending on the use-case).

      When using SSO, the token provided by the SSO provider (i.e. your system) is validated and exchanged for a token provided by FMI.  This token exchange adds the additional authorization information required by FMI.