fix(backend): reject a replayed TOTP code within its validity window (#1389)

* fix(backend): reject a replayed TOTP code within its validity window

verifyTotp() was stateless — otplib's window:1 tolerance meant the
same 6-digit code could complete two independent logins inside its
~90s validity window. Track each admin's last-consumed step and
reject a code that doesn't advance past it.

* fix(backend): make the TOTP replay-tracking persist atomic

verifyTotpEncryptedStep() read two_factor_last_used_step, then a plain
UPDATE wrote the new step with no conditional guard — two concurrent
requests carrying the same captured code could both pass the check
before either UPDATE landed. The persist is now a conditional UPDATE
(only advances the step, checked via affected-row count), so a losing
concurrent request is correctly treated as a replay.

---------

Co-authored-by: Paul Nothaft <[email protected]>

This commit is contained in:

Paul Nothaft

2026-09-11 10:40:27 +02:00

committed by

GitHub

co-authored by

Paul Nothaft

parent e3247911a0

commit cdde937d7f

7 changed files with 426 additions and 13 deletions

									
										backend/scripts/reset-admin-mfa.js
									
		+1
		
												View File
												
				@@ -36,6 +36,7 @@ const MFA_CLEAR = {

				  two_factor_secret: null,

				  two_factor_recovery_codes: null,

				  two_factor_enrolled_at: null,

				  two_factor_last_used_step: null,

				  updated_at: new Date(),

				};