Analyzing Multi-Factor Authentication Through Cryptographic Security Properties

• TOTP uses HMAC, while push-based authentication relies on digital signatures and secure communication channels.Source: §I · p. 1
• Even with sound cryptographic methods, weak enforcement of freshness, session binding, or state consistency can leave systems vulnerable to replay, token reuse, and unauthorized approvals.Freshness limits token validity; session binding ties authentication to a particular session; state consistency requires the server to track the authentication process.Source: §I · p. 1
• The project evaluates TOTP and push-based MFA under different conditions to identify failures in these properties and their security impact.Source: §I · p. 1

• Reynolds et al. found that more than 1 in 20 university MFA authentication attempts failed, with timeouts, user behavior, and session handling affecting practical performance.Source: §II · p. 1
• Bonneau et al. found that no authentication system achieves all desired security, usability, and deployability properties at once.Source: §II · pp. 1–2
• Mahdad et al. demonstrated that attackers can exploit protocol and user-interaction weaknesses in push-based MFA to manipulate users into approving malicious login requests.Source: §II · p. 2
• This project extends prior work by directly testing implementation enforcement of freshness, session binding, and server-side state management.Source: §II · p. 2

• The TOTP setup placed the login interface, OTP generation, tests, and credentials locally, while a remote VPS hosted Flask behind Nginx.The Flask application handled OTP verification, credential validation, and replay protection through an in-memory used_tokens guard.Source: §III · p. 2, Figure 1 · p. 2
• The push setup used a local machine for simulated interaction and a remote VPS for Flask and Nginx, with endpoints for approval or denial and MFA status checking.Tests covered replay behavior, cross-session approval reuse, and state-loss conditions.Source: §III · p. 2, Figure 2 · p. 2
• The systems were developed and checked locally, then deployed on separate VPSs so each authentication method could be evaluated independently in a remote setting.Source: §III · p. 2
• Freshness tests varied code and approval validity windows to examine whether longer expiration times increased opportunities to reuse intercepted responses.Source: §III · p. 3
• Session-binding tests checked whether an MFA response could be reused across login attempts, while state tests examined used tokens, expired codes, and completed approvals.The state tests focused on whether repeated submissions were rejected and how weak or absent server-side tracking could permit replay or unauthorized access.Source: §III · p. 3

• Freshness testing examined how each system enforced the validity period of authentication responses.The tests isolated this property under normal and intentionally weakened configurations.Source: §IV · p. 3
• Session-binding testing examined whether authentication responses were tied to a particular login attempt.The tests isolated this property under normal and intentionally weakened configurations.Source: §IV · p. 3
• State-management testing examined how each system handled server-side authentication state.The tests isolated this property under normal and intentionally weakened configurations.Source: §IV · p. 3

A. Test 1: Progressive Replay Window Expansion

• The test expanded TOTP windows from ±1 to ±2 and ±4 and push approval expiry from 5 to 30 and 120 seconds, replaying captured responses at increasing delays.The TOTP default ±1 window was approximately 60 seconds.Source: A. Test 1: Progressive Replay Window… · p. 3
• At TOTP ±4 (~150 seconds), all replayed tokens were accepted regardless of delay, making man-in-the-middle replay feasible.At the default TOTP ±1 window (~60 seconds total), replayed tokens were rejected after 60 seconds; push expiry showed a similar pattern.Source: Table I · p. 3, A. Test 1: Progressive Replay Window… · p. 3
• Push MFA's 5-second expiry was highly restrictive, while 120 seconds gave an attacker enough time to redirect and reuse an approval.TOTP ±1 and push with a 30-second expiry represented equivalent default security postures.Source: Table II · p. 3, A. Test 1: Progressive Replay Window… · p. 3

B. Test 2: Cross-Session Confusion Under Load

• The test opened 10 concurrent login sessions, submitting one TOTP code across them and generating a distinct push request for each push session.The push requests had unique identifiers.Source: B. Test 2: Cross-Session Confusion… · p. 3
• Without prevention, one TOTP code authenticated all 10 sessions; with a used_tokens blacklist, only one succeeded and the other nine were denied.The results identify explicit server-side state as necessary to enforce TOTP single-use behavior.Source: B. Test 2: Cross-Session Confusion… · p. 4, Table III
• Push UUIDs made cross-session confusion architecturally impossible; all 10 sessions were approved independently with zero collisions.Each push request could only be approved or denied within its original session.Source: Table IV · p. 4, B. Test 2: Cross-Session Confusion… · p. 4

C. Test 3: State Loss and Server Restart

• The test restarted the server mid-session and replayed previously captured tokens and approval responses against the restarted server.The restart simulated a crash, scheduled maintenance, or an attacker-induced denial-of-service event.Source: C. Test 3: State Loss and Server Restart · p. 4
• After restart, the cleared in-memory TOTP used_tokens list allowed a previously rejected captured token to be accepted without restriction.The authors note that an attacker able to trigger a restart could replay an intercepted code to gain unauthorized access.Source: Table V · p. 4, C. Test 3: State Loss and Server Restart · p. 4
• After restart, push sessions were invalidated with 401 Unauthorized responses rather than accepting old tokens, forcing legitimate users to reauthenticate.This creates a denial-of-service condition for users with active sessions.Source: Table VI · p. 4, C. Test 3: State Loss and Server Restart · p. 4

• Both MFA methods became vulnerable when validation windows were widened, token tracking was removed, or the server was restarted, despite correct underlying cryptography.Source: §V · p. 5
• Push-based MFA binds each login attempt to a unique ID, while TOTP can be accepted across sessions without a server-side used-token blacklist.Source: §V · p. 5
• A server restart clears in-memory authentication state, enabling replay of captured TOTP tokens and terminating active push sessions.Persistent storage, such as a database, would directly address this weakness.Source: §V · p. 5
• MFA security depends on correct implementation around cryptographic algorithms, including proper window sizing, persistent state, session binding, and single-use token enforcement.Source: §V · p. 5