TOTP2 Authentication Scheme

Introduction The TOTP2 authentication scheme builds on the Time-Based One-Time Password (TOTP) algorithm method defined in . It enhances the security by incorporating two TOTP shared secrets, strictly linked to a specific service, and provides a mechanism for securely transferring and verifying TOTP codes via HTTPS. TOTP2 offers enhanced protection against phishing attacks without penalizing the user experience. The TOTP2 scheme replaces manual code input with a secure submission process directly from the TOTP2 authenticator to a verification URL tied specifically to the service being authenticated. By performing an XOR operation on the two one-time codes, the authentication scheme ensures that the on-screen one-time code becomes meaningless to potential attackers. The authentication process can be further streamlined through the use of QR codes and automatic submission from the authenticators, simplifying the user experience. The TOTP2 authenticator requires an active Internet connection to facilitate the communication and submission of generated codes.

Naming The name "TOTP2" is intended to be understood as TOTP "duo" rather than a TOTP versioning scheme. This naming choice reflects the use of two secret keys and codes in the authentication scheme, emphasizing the dual nature of the authentication process.

Background The usage of two codes in the TOTP2 authentication scheme offers distinct advantages over using a single TOTP code, as outlined below: Authentication of the Service: The service-provided one-time code serves as a means of authenticating the service to the user. By presenting this code, the service demonstrates that it possesses the shared secret, thus assuring the user that they are interacting with the genuine service and not a phishing attempt. This additional layer of authentication enhances security and instills trust in the user. Session Identification: The one-time code can be utilized to identify and manage multiple active sessions. Each session can be associated with a unique one-time code, allowing for the simultaneous authentication of multiple sessions. This capability enables greater flexibility and convenience, particularly in scenarios where users may need to access the service from multiple devices or locations concurrently. By incorporating two codes in TOTP2, the authentication process becomes more robust and versatile, providing enhanced security and improved user experience. The traditional one-time code verification process is susceptible to phishing attacks since attackers can reuse the code within its validity window. To counter this threat, TOTP2 enhances security by using a non-interactive channel to submit the one-time code. By using a non-interactive channel, such as an automated submission process directly from the TOTP2 authenticator to the service's verification endpoint, the user is not required to manually input the one-time code. This reduces the risk of exposing the code to potential phishing attacks during the submission process. The non-interactive channel ensures that the one-time code is securely transmitted to the service, reducing the window of opportunity for attackers to intercept and reuse the code. This approach significantly enhances the security of the TOTP2 authentication scheme and provides increased protection against phishing attempts.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . TOTP: Time-Based One-Time Password, an algorithm that generates one-time passwords based on a shared secret and the current time. Service: The entity or application that requires TOTP codes for authentication. TOTP2: The scheme that enables the secure transmission of TOTP codes from a TOTP2 authenticator to a service, incorporating two shared secrets. Authenticator: An application installed on a user's device that verifies, generates, and submits TOTP2 one-time codes.

Authentication Scheme Overview The TOTP2 scheme follows these steps: TOTP2 Registration: The user initiates the registration process on the TOTP2 authenticator by providing the necessary information provided by the service. Service OTC Generation: During authentication with the service, the service generates an on-screen one-time TOTP code intended for the user's TOTP2 authenticator. Service OTC Verification: The TOTP2 authenticator verifies the received TOTP code. If the verification fails, the authentication process is interrupted. Client OTC Generation: Using the registered service information and the provided service one-time code, the TOTP2 authenticator generates its own TOTP2 one-time code. TOTP2 Code Submission: The TOTP2 authenticator securely submits the generated TOTP2 code to the service. Authentication: The service receives the TOTP2 code and verifies it to complete the authentication flow.

Detailed Scheme Description

TOTP2 Registration The TOTP2 registration process starts with the user initiating the registration on the TOTP2 authenticator. During registration, the user provides the authenticator with the required information provided by the service, which includes the two shared secrets, "service_secret" and "client_secret," along with the "verification_endpoint" URI for TOTP2 code submission. Once the registration is complete, the provided information, including the shared secrets and verification endpoint, is securely stored locally on the TOTP2 authenticator for future use. To simplify the registration process, QR codes are commonly used to transfer the information to the authenticator. The service registration information is encoded as an OTP URI within the QR code, containing all the required service details. Once the registration information is provided, the authenticator generates a TOTP OTC (One-Time Code) for each shared secret. These codes are then combined using an XOR operation, resulting in the final TOTP2 code. This final code is then submitted to the provided endpoint to conclude the registration process.

Registration URI The OTP URI format for TOTP2 service registration is as follows:

The LABEL is used to identify which account a key is associated with. It contains an account name, which is a URI-encoded string, optionally prefixed by an issuer string identifying the provider or service managing that account. This issuer prefix can be used to prevent collisions between different accounts with different providers that might be identified using the same account name, e.g., the user's email address. The issuer prefix and account name should be separated by a literal or URL-encoded colon, and optional spaces may precede the account name. Neither the issuer nor the account name may contain a colon. The representation in ABNF according to is as follows:

Valid values for LABEL might include examples like: "Example:alice@gmail.com" "Provider1:Alice%20Smith" "Big%20Corporation%3A%20alice%40bigco.com" We recommend using both an issuer label prefix and an issuer parameter, described below. The PARAMETERS provided in the TOTP URI format include: password_entry: A 'yes' or 'no' (default) value, indicating whether the password entry should be made within the authenticator service_secret: The shared secret used by the service to generate codes for verification in the TOTP client app. client_secret: The shared secret used by the TOTP client app to generate TOTP codes for verification by the service. algorithm: The algorithm used for generating the TOTP codes (e.g., SHA1, SHA256). digits: The number of digits in the generated TOTP codes (e.g., 6, 8). counter: The initial counter value for the TOTP algorithm. period: The time period (in seconds) for which a TOTP code is valid. verification_endpoint: The URL to which the TOTP client app should submit the client TOTP code and previously received service code. It must start with "https://" protocol prefix.

Service OTC Generation Upon authentication request, the service generates a one-time code based on the service secret (service_secret) associated with the user's account. This code is then used to construct a QR code containing a TOTP2 request for the authenticator. The QR code includes the following value represented in ABNF syntax:

The LABEL SHOULD BE the same as the one provided in the OTP registration URI. OTC represents the generated TOTP one-time code using the service secret. The TIMESTAMP represents a Unix timestamp identifying the time of otc generation. The QR code serves as a visual representation of the TOTP2 request, allowing for easy transfer of the code to the authenticator app. Valid request might include examples such as: "Example:alice@gmail.com:1689694239" "Provider1:Alice%20Smith:1689694239" "Big%20Corporation%3A%20alice%40bigco.com:1689694239" These examples demonstrate how the label and one-time code can be combined within the TOTP2 request for inclusion in the QR code.

Service OTC Verification Upon scanning the QR TOTP2 request with the authenticator application, the authenticator decodes the information contained within. The authenticator performs the following actions: Time Synchronization Check: The authenticator compares the Unix timestamp obtained from the QR code with the local time. If the time difference exceeds a certain threshold, indicating a significant time discrepancy, the authentication fails. In such cases, an out-of-sync warning is presented to the user, indicating the need for time synchronization. Account Identification: If the authenticator supports multiple accounts, it uses the label part of the TOTP2 request to identify the corresponding registered account. The label acts as a unique identifier for the account within the authenticator. TOTP Code Verification: Using the service secret associated with the identified account, the authenticator verifies the provided TOTP code. The TOTP code is generated based on the client secret and the current time. Authentication Result: If the registered account is successfully identified and the provided TOTP code is verified, the authentication process is considered successful, granting access to the service. However, if no registered account can be identified using the label or the provided TOTP code fails to verify, the authentication process fails. In case of authentication failure, appropriate feedback is presented to the user, indicating the reason for the failure, such as an incorrect label or an invalid TOTP code.

Client OTC Generation After successfully verifying the service-provided TOTP one-time code, the TOTP2 authenticator generates a new TOTP one-time code using the "client_secret." The authenticator then performs a bitwise XOR operation between the service-provided one-time code and the newly generated one-time code. This XOR operation results in a new combined TOTP2 code, which is now ready for submission to the service.

Optional Password Entry The TOTP2 scheme provides an optional feature known as "Optional Password Entry." In typical TOTP implementations, when the second-factor authentication is initiated, some form of primary authentication has already occurred. However, in phishing scenarios, the user's credentials might have been stolen before the TOTP authentication takes place. To enhance security further, the TOTP2 registration process includes a "password_entry" parameter. When this parameter is present and set to "yes," the password entry is deferred until after the TOTP2 authentication. Once the TOTP2 authenticator generates the TOTP2 one-time code, it prompts the user to enter their password. The user then provides the password, and both the TOTP2 code and the password are submitted together to the service for final authentication. By deferring the password entry until after TOTP2 authentication, this optional feature adds an extra layer of security, reducing the risk of exposing the password to potential phishing attempts during the initial authentication phase.

TOTP2 Code Submission The verification URL for TOTP2 code submission follows the format: VERIFICATION_ENDPOINT ("?" / "&") PARAMETERS The VERIFICATION_ENDPOINT is provided during the TOTP2 registration process, which must begin with the 'https://' protocol prefix. The PARAMETERS included in the verification URL are as follows: "code": The TOTP2 one-time code generated by the TOTP2 authenticator application. "account": The account name provided during the TOTP2 authenticator registration, present in the TOTP2 OTP URI as label. If the verification endpoint already includes query parameters, the new parameters SHOULD be correctly appended. To ensure secure submission of the TOTP2 code, the TOTP2 authenticator application makes an HTTP GET request using the HTTPS protocol defined in . If an untrusted HTTPS connection is detected, the authentication process MUST fail. A successful authentication is indicated by receiving a HTTP 2xx status code. The response body of the message should be discarded. Any other status code indicates a failed authentication.

Authentication Upon receiving the TOTP2 code from the user, the service performs the following steps to validate the code and authenticate the user: The service looks up the corresponding account associated with the TOTP2 code. Using the shared secrets (service_secret and client_secret), the service calculates its own TOTP2 code. The service compares the calculated code with the received TOTP2 code. If the codes match, the validation is successful, and the user is considered authenticated. The service grants the user access to the requested service or resources. In response to the code submission request, the service sends an HTTP 2xx status code to indicate a successful authentication process. If the TOTP2 code fails to validate, the authentication flow on the user's screen indicates a failure, and the user is not granted access to the service or resources.

Recovery Procedure Authenticators can be lost or become inaccessible, making it essential for service providers to establish a reliable recovery procedure for users. While the specifics of the account recovery process vary between providers, one common approach is the use of recovery keys during TOTP2 registration. Recovery keys serve as a secondary authentication factor and should be securely stored by users. In case of losing access to the authenticator, users can utilize these keys to regain account access. However, it is crucial to emphasize that recovery keys should only be used on trusted devices. By limiting the usage of recovery keys to trusted devices, service providers can mitigate the risk of unauthorized account access. Trusted devices are previously authorized and meet security criteria such as device registration or multi-factor authentication. Service providers should validate the trustworthiness of devices during the recovery process, ensuring their identity and adherence to security measures. This helps maintain the overall security of the account recovery process and protects user accounts from unauthorized access. Clear documentation and instructions on using recovery keys should be provided to users, making the recovery procedure easily accessible. Service providers should also consider security implications and implement appropriate measures to safeguard user accounts during the recovery process.

Security Considerations The TOTP2 scheme introduces several security considerations to ensure the confidentiality and integrity of the authentication process: Strong Encryption: The side channel communication between the TOTP2 authenticator and the service should utilize strong encryption mechanisms. This protects the confidentiality and integrity of the transmitted data, preventing unauthorized access or tampering. Verification of Service-Generated Code: The service-generated code provided to the user must be verified to prevent man-in-the-middle and phishing attacks. Users should carefully validate the code to ensure they are communicating with the authentic service and not an imposter. Secure Storage of Secrets: Both the service secret and client secret should be securely stored and protected. Unauthorized access to these secrets could compromise the security of the TOTP2 authentication process. Measures such as encryption and access controls should be implemented to safeguard the secrets. Validation of TLS Certificate: The TOTP2 client app should validate the TLS certificate presented by the service. This ensures that the communication is established with the legitimate service and helps prevent potential phishing attacks. Separate Authenticator and Authenticated Devices: It is recommended to use separate devices for the TOTP2 authenticator and the device being authenticated. This reduces the risk of exposing sensitive authentication information if the same device is compromised. By addressing these security considerations, service providers can enhance the overall security of the TOTP2 authentication process and protect user accounts from unauthorized access and attacks.

IANA Considerations This document has no IANA actions.