POLYMORPHIC TIME-BASED

OFFSET AUTHENTICATION

A Framework for Temporally-Derived Dynamic Authentication

Abstract

This paper presents Polymorphic Time-Based Offset Authentication (PTBOA), a novel authentication framework that replaces static or semi-static second-factor authentication mechanisms with a continuously shifting, date-derived challenge-response system.

Traditional multi-factor authentication relies on shared secrets that are either static (passwords, hardware tokens with fixed seeds) or time-based with publicly known algorithms (TOTP/RFC 6238). Both approaches share a fundamental vulnerability: the verification algorithm is known and the secret, once exposed, is permanently compromised.

PTBOA introduces temporal polymorphism into the authentication layer. The verification function itself shifts daily based on date-derived variables, creating 365 unique daily barrier states per calendar year. An attacker who successfully captures today's valid response cannot replay it tomorrow, cannot predict tomorrow's valid response without knowing the date-derivation function, and cannot enumerate valid responses without triggering detection.

This paper describes the conceptual framework, threat model, entropy analysis, silent failure protocol, and audit methodology of PTBOA. Implementation-specific values are intentionally withheld per the principle of security through obscurity of parameters, not through obscurity of design.

Document Structure

The Offset Variable: T + f(Date)

The foundational innovation of PTBOA is the introduction of a date-derived function into the authentication challenge-response cycle. In conventional time-based authentication (TOTP), the time variable T creates a 30-second window during which a given code is valid. The algorithm generating that code is public (RFC 6238) and the secret seed, if compromised, permanently exposes the authentication layer.

PTBOA replaces the static seed with a date-derived offset function f(Date) that transforms the challenge-response relationship daily. The verification function takes the form:

The 365 Barrier Property

Because f(Date) produces a distinct output for each calendar date, the authentication barrier state is unique for every day of the year. A response valid on day D is invalid on day D+1 even if all other conditions are identical. This property has several important consequences:

• Captured credentials have a maximum validity window of the current calendar day
• Replay attacks require both the captured response AND knowledge of the date-derivation function
• Brute force enumeration of valid responses requires solving f(Date) for each target day independently
• Credential stuffing attacks from historical breaches are categorically ineffective

Non-Linearity of the Temporal Offset

The security of the 365-barrier property depends on f(Date) being non-linear — that is, knowing f(D) and f(D+1) should not reveal f(D+2). A linear date function (such as simply using the day-of-year integer) provides only superficial protection since the sequence is trivially predictable.

A well-constructed f(Date) exhibits the following properties:

• Avalanche effect: Small changes in the date input produce large, unpredictable changes in output
• Non-monotonicity: The output sequence does not increase or decrease predictably over time
• Collision resistance: No two dates within a reasonable window produce the same output
• Computational asymmetry: Forward computation (given date, compute offset) is fast; reverse computation (given offset, find date) is infeasible without the function definition

The Silent Failure Protocol

A critical vulnerability in most authentication systems is information leakage through error responses. When a system returns different error codes, messages, or response timings for different failure conditions, an attacker can use this information to narrow the attack surface through a process called side-channel enumeration.

The Side-Channel Enumeration Problem

Consider a conventional authentication system that returns:

• 'Invalid username' when the user does not exist
• 'Invalid password' when the user exists but password is wrong
• 'Invalid 2FA code' when password is correct but 2FA fails

This response structure reveals the authentication layer that failed, allowing an attacker to confirm valid usernames, then focus password attacks on confirmed accounts, then focus 2FA attacks only after password success. Each layer of the authentication stack becomes independently attackable.

PTBOA Silent Failure Implementation

The Silent Failure Protocol mandates that the authentication system return a single generic denial response regardless of which layer failed and why. The external behavior of the system is identical whether:

• The username does not exist
• The password is incorrect
• The temporal offset response is invalid
• The request is malformed
• The account is locked or suspended
• The date-derivation function produces an unexpected value

Timing Attack Mitigation

Silent failure requires more than identical messages — it requires identical response timing. If a valid username produces a 50ms response (because the system queries the database) and an invalid username produces a 2ms response (because the system fails immediately), timing analysis reveals valid usernames even when error messages are identical.

PTBOA implementations should enforce a minimum response time for all authentication attempts regardless of failure point, adding randomized jitter to prevent timing correlation across multiple requests.

Compliance and Normality

A sophisticated security architecture creates a compliance paradox: the more complex the security mechanism, the more difficult it becomes to demonstrate compliance to external auditors without revealing implementation details that compromise security.

PTBOA resolves this paradox through the principle of Audit-Transparent, Client-Opaque design.

The Audit-Transparent, Client-Opaque Principle

The system presents two distinct views simultaneously:

• Client-facing view: Standard authentication interface indistinguishable from conventional 2FA. The user sees a normal login flow. The external digital footprint appears standard and compliant.
• Server-side view: High-security analysis layer processing the temporal offset verification. The actual security mechanism is entirely server-side and invisible to the client.

This separation means that a surface-level audit of the client-facing interface reveals a normal, compliant authentication system. The deep security mechanism exists entirely within the server-side processing layer where it cannot be observed, reverse-engineered, or enumerated by external parties.

Maintaining a Normal Digital Footprint

The authentication endpoint should be structurally identical to conventional authentication endpoints. Request format, response format, HTTP status codes, and header structure should conform to standard patterns. Deviation from standard patterns creates fingerprinting opportunities that reveal the presence of non-standard security mechanisms.

Regulatory Compliance

PTBOA's client-opaque design supports compliance with authentication requirements across major regulatory frameworks. The externally visible authentication flow satisfies standard MFA requirements. The internal temporal offset mechanism provides additional security that exceeds baseline requirements without requiring disclosure of implementation specifics.

Compliance documentation can accurately describe the system as implementing time-based multi-factor authentication without disclosing the date-derivation function that constitutes the proprietary security enhancement.

Audit Methodology

PTBOA's audit framework is designed to allow authorized observers to verify the integrity and correctness of the security logic without requiring access to the specific parameter values that constitute the implementation secret.

The Two-Layer Audit Model

Authentication system audits typically verify two distinct properties: that the system implements the claimed mechanism correctly, and that the specific values used are appropriate. PTBOA separates these concerns explicitly.

• Logic audit: Verifies that the date-derivation function f(Date) exhibits the required properties (non-linearity, avalanche effect, collision resistance) without revealing the specific function
• Parameter audit: Verifies that the parameter values are stored securely and not logged, transmitted, or exposed through any channel — without revealing the values themselves

Generic Formula Disclosure

For audit purposes, PTBOA implementations disclose the generic structural formula while withholding variable-specific values:

This approach allows an auditor to verify that the system implements a date-dependent offset mechanism, that the offset is applied correctly in the verification function, that the failure handling follows the silent failure protocol, and that no implementation details are logged or transmitted in clear text.

The auditor cannot, however, use the audit findings to construct a valid response for any target date — because the specific values of the derivation function are never disclosed.

Audit Evidence Package

A PTBOA implementation audit should produce the following evidence without revealing implementation secrets:

• Structural formula disclosure (generic, as described above)
• Proof of non-linearity: Test vectors showing that sequential date inputs produce non-sequential outputs
• Silent failure demonstration: Traffic captures showing identical external behavior across all failure conditions
• Parameter security: Evidence that implementation values are not stored in logs, transmitted over networks, or accessible through any external interface
• Timing consistency: Statistical analysis demonstrating uniform response timing across success and failure conditions

Threat Model

Threats Mitigated by PTBOA

• Credential replay attacks: Captured valid responses expire at end of current calendar day
• Historical breach exploitation: Credentials from past breaches are invalid due to date offset evolution
• Side-channel enumeration: Silent failure protocol prevents information leakage through error responses
• Timing analysis: Uniform response timing prevents failure-layer identification
• Algorithm enumeration: Non-public date-derivation function prevents offline response generation
• Brute force: Each day's valid response space requires independent solving of the date-derivation function

Threats Requiring Additional Controls

• Real-time man-in-the-middle: If an attacker captures and relays a valid response within the same calendar day, PTBOA's daily rotation does not prevent this — network-layer TLS and certificate pinning remain essential
• Server-side compromise: If the implementing server is fully compromised, the date-derivation function is exposed — physical and infrastructure security controls remain necessary
• Social engineering: PTBOA does not protect against users being deceived into voluntarily providing valid responses
• Insider threats: Individuals with legitimate server access can observe the implementation — access controls and separation of duties are required

Entropy Analysis

The security of PTBOA's temporal offset mechanism depends on the entropy of the date-derivation function output. This section establishes the minimum entropy requirements for a secure implementation.

Baseline Entropy: Calendar Date

This baseline represents the lower bound for a trivial implementation that uses the raw day-of-year integer as the offset. Such an implementation is insufficient for production use because the output sequence is trivially predictable.

Required Entropy: Non-Linear Transform

A production f(Date) function must expand the effective entropy beyond the 8.51-bit baseline through non-linear transformation. The target entropy depends on the threat model, but a minimum of 64 bits of effective security is recommended for systems protecting high-value assets.

Entropy Conservation Across Days

A critical property of a secure f(Date) is that knowing the output for N consecutive days provides no useful information about the output for day N+1. This property — analogous to the next-bit test in cryptographic pseudorandom number generators — ensures that temporal observation of the authentication system does not enable prediction of future valid responses.

Implementation Guidance

This section provides structural recommendations for PTBOA implementations without disclosing specific values. These guidelines describe what a correct implementation looks like, not how to construct one.

Server-Side Isolation

The date-derivation function and all associated parameters must exist exclusively in server-side processing. Implementation specifics must never appear in client-side code, API responses, error messages, logs, or any externally observable channel.

Parameter Storage

Implementation parameters should be stored in environment variables or a hardware security module, never in source code repositories, configuration files checked into version control, or database records accessible through application queries.

Audit Logging

Audit logs should record authentication attempts (success or failure), timestamps, and source identifiers without recording the specific offset values or derivation function outputs involved in the verification. Logs must be useful for security monitoring without being useful for offline attack construction.

Key Rotation Considerations

The date-derivation function itself should be rotatable — that is, the system architecture should support replacing f(Date) with a new function without service interruption. A rotation event should be treated with the same security controls as a cryptographic key rotation.

Conclusion

Polymorphic Time-Based Offset Authentication represents a meaningful advancement over static and conventional time-based authentication mechanisms. By introducing date-derived temporal polymorphism into the verification function, PTBOA creates a continuously shifting authentication barrier that degrades the value of captured credentials, eliminates the replay attack surface beyond a single calendar day, and provides a compliance-compatible external interface while maintaining deep server-side security.

The Silent Failure Protocol closes side-channel information leakage that undermines conventional multi-factor authentication deployments. The Audit-Transparent, Client-Opaque design allows regulatory compliance verification without compromising implementation security.

PTBOA is not a replacement for foundational security controls — network security, access management, and infrastructure hardening remain essential. It is a meaningful enhancement to the authentication layer that introduces temporal entropy properties not present in any publicly documented authentication standard.

The conceptual framework described herein is complete. The specific implementation parameters that constitute the actual security mechanism are intentionally absent from this document and exist solely in the implementing system.