Two-Factor Authentication (2FA) can be a crucial part of your organization's security requirements, and not being able to connect due to problems with your configuration can be frustrating. Here are things to look for when user accounts using 2FA are not able to connect.

Problems Using TOTP Authentication

When using an authenticator app / Time-based one-time password (TOTP) 2FA method, the clock of your device must be kept up-to-date. If the difference between the client (generating the TOTP) clock and the Files.com platform is larger than just a few seconds, it can lead to authentication failures. You should ensure that the your device clock is synchronized using Network Time Protocol (NTP) or similar time synchronization mechanisms to prevent authentication issues due to clock drift.

2FA codes have a short lifespan, typically under a minute. If the code is nearing its expiration, wait for the next one to be generated.

Problems Using SMS Authentication

SMS Messages for authentication should be sent almost immediately after your user logs in. If no message has arrived within a few minutes, attempt to re-connect. If a message does not arrive within a few minutes, try restarting the device, which can sometimes resolve temporary network or connectivity issues.

Ensure that the device has a strong signal and good network connectivity to receive SMS messages. Make sure the phone is not in "Do Not Disturb" mode.

Files.com uses the Twilio service to send SMS messages, and you can check the status of Twilio's services to see if the recipient's region is affected by an outage.

Problems With 2FA and SFTP

Using 2FA with an SFTP connection is possible, but not recommended. A connection made by a human (required for supplying a second factor during authentication) should not use SFTP unless absolutely necessary; we recommend using one of our preferred file transfer applications, such as the CLI or Desktop Application.

Users with some form of password authentication and 2FA can be configured to Bypass 2FA for FTP, SFTP and WebDAV. If users are authenticating with ecdsa-sk or ed25519-sk key types, those keys will require the authentication method that was used for their creation, but their user account cannot make use of Files.com-controlled 2FA.

Existing FTP/SFTP/DAV users won’t be able to authenticate until they log into the web app to set up their 2FA method when 2FA is enabled, either site-wide or at the user level. This setup is required even if an admin allows these users to bypass two-factor authentication.

Problems With Email Authentication

If a user has configured an Email 2FA Method, but they are not receiving the emails, you have several tools to track down the issue. You can use the Outbound Emails Log to determine when the email was sent.

Your recipient should check their spam folders to verify that the email titled "Verification Code" was not automatically hidden from their inbox.

If the email was sent but did not arrive at the recipient, it may be due to your user's exchange servers blocking or rejecting emails from Files.com. Within your organization's network, certain intermediate servers like email gateways, forwarders, mail transfer agents, or security systems can modify email content or headers for tagging or classification purposes during transit. This can lead to changes in the subject line, headers, or email content, potentially causing issues with DKIM signature validity or DMARC/SPF validation. If this happens, it could result in your mail servers rejecting Files.com emails. To address this, we recommend reviewing the settings of your organization's intermediate servers to resolve email authentication problems.

Session IP Address Pinning

Site administrators can enable Session IP Address Pinning, which will force users to re-authenticate whenever their IP address changes. Enabling this setting is not recommended for most organizations.

If a user is continually being unexpectedly prompted to log into the site, check to see if session IP address pinning is enabled. Disabling the site setting may fix the authentication problem for that user.

Rate Limiting

When the wrong 2FA code is provided too many times in a row, further attempts to authenticate will be rate-limited. An error message will be returned to indicate that too many attempts have been made to authenticate.

To solve this problem, wait before attempting to reconnect. Resetting the 2FA method will not decrease the time the user must wait before trying again.

Waiting Period When Removing 2FA Mandate

When a site administrator changes the site's settings to remove a requirement for 2FA, a 7 day waiting period is enforced as a security measure. Until 7 days have elapsed, users will not be able to remove their last 2FA method, and new users must enable at least one 2FA method.

Enable/Disable 2FA for SSO users

Provisioning users via an SSO provider allows you to automatically configure whether each user account requires 2FA. When you configure the SSO provider, you can change the Provision users with 2FA required? setting to choose whether users created by that SSO provider should use 2FA. This setting can be entirely independent of your site's Enforce two-factor authentication setting, which would apply to any users who are not provisioned by that SSO provider.

For example, imagine you have two sets of users - internal staff members who authenticate using an SSO provider, and a set of users who are external to your organizations. If you want to require 2FA for your external users only, you can configure your site's Enforce two-factor authentication setting to Required for All users and then change your SSO provider's Provision users with 2FA required? setting to Never require two-factor authentication.