How To: Use Both 30-Second and 60-Second TOTP Intervals for 2FA

Version Affected: 9.2 and later

 

Overview

SecureAuth Authenticate supports any Time-Based One-Time Passcode (TOTP) interval, but Google Authenticator and Microsoft Authenticator only support a 30-second interval (see FAQ: What Time Intervals and Passcode Lengths Does Each Authenticator App Support? for the full comparison). This article explains how to support both a 60-second interval, using an OATH Seed, and a 30-second interval, using an OATH Token, at the same time — so existing 60-second enrollments keep working while new users can enroll at 30 seconds. See FAQ: What Is the Difference Between an OATH Seed and an OATH Token? for how each of these works.

Supporting Both Intervals at the Same Time

In this example, the environment is already configured for 60-second intervals using an OATH Seed. The goal is to keep those existing 60-second enrollments working while allowing new users to enroll at 30 seconds using an OATH Token.

1. Set up an OATH Token realm to enroll users at 30-second intervals. Either QR or URL enrollment works. On the Data tab, make sure to map an attribute that is writable to OATH Token.
2. Map that same attribute to OATH Token on every Authentication Realm where you want 30-second intervals to be usable.
3. Do not change any of the Time-Based Passcode (OATH) settings on the Multi-Factor Methods tab of the Authentication Realm. An OATH Token does not rely on those settings to generate its TOTP — only an OATH Seed does.

If you want to convert existing OATH Seed values to OATH Tokens, mark the OATH Token attribute as writable on your Authentication Realms in step 2. The next time a user logs in with TOTP, their 60-second OATH Seed is converted to an OATH Token using the settings from step 3.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.