HomeAuthentication & SSOLocal directory authentication

Local directory authentication

How Interact stores and protects local directory passwords, and the reset, complexity, magic-link and social sign-in options you can enable.

Local directory accounts are held within Interact for users who do not sign in through an external identity provider. This page explains how those passwords are protected, how users recover access, and the sign-in options you can enable.

Before you start

  • You need a Power User account to change authentication and password settings.
  • Local directory authentication applies to users whose accounts are managed in Interact rather than through SAML single sign-on. If all of your users sign in through an identity provider, see Configure SAML single sign-on instead.

All of the settings on this page are in Control Panel > Application Variables, in the Authentication section.

How passwords are stored

Interact never stores local directory passwords in plain text. Each password is protected with a one-way hash combined with a unique salt:

  • One-way hash — the password is run through a hashing algorithm that cannot be reversed, so the original password cannot be recovered from what is stored, even by Interact.
  • Salt — a unique random value is added to each password before hashing, so two users with the same password produce different stored values, and precomputed ("rainbow table") attacks do not work.

When a user signs in, the password they enter is hashed with the same salt and compared to the stored value; the plain-text password is never retained.

Resetting a password

Users recover access themselves through the standard forgotten password flow: from the sign-in screen they request a reset, Interact emails them a secure reset link, and they set a new password. Because passwords are stored as one-way hashes, an existing password can never be retrieved or emailed — it can only be reset.

Password complexity requirements

You can enforce a password policy for local directory accounts so that passwords meet your organisation's security standards. The policy is highly configurable:

  • Regular-expression pattern matching — complexity rules are defined as a regular expression, so you can require any combination of length, character classes and patterns. For example, the following requires at least eight characters including a lower-case letter, an upper-case letter and a digit:

text ^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,}$

  • Custom guidance text — set your own message describing the requirements, shown to users as they choose a password, so the wording matches your policy.
  • Custom error text — set the message shown when an entered password does not meet the requirements.
  • Forbid names in passwords — optionally prevent a password from containing the user's first name or last name.

Tip: Write the guidance text in plain language that mirrors the regular expression, so users understand the rule without having to interpret the pattern.

Passwordless and social sign-in

Alongside passwords, you can enable additional sign-in methods for local directory accounts:

  • Magic link — users can sign in with a one-time link sent to them by email or SMS, instead of entering a password.
  • Social sign-in (mobile app only) — you can enable Google and Apple sign-in for users of the Interact mobile app. These social options apply to the mobile app only and are not available on the web.

Note: Enable only the sign-in methods your security policy allows. A Power User turns magic-link and social sign-in on in Control Panel > Application Variables, in the Authentication section.

Section: Authentication & SSO