UsersController.resetPassword in application/backend/src/controllers/UsersController.ts marks a used token via passwordResetTokenRepo.update({ ..., data: { used: true } }) but never deletes the row. Every password reset ever completed sits in the PasswordResetToken table indefinitely, and there's no scheduled cleanup for used or expired tokens either.
Meanwhile, in the same codebase, AuthController.loginOtp explicitly deletes the OTP token on use: await prisma.oTPToken.delete({ where: { id: otp.id } }). So there are two auth tokens with two different retention policies in the same file tree, presumably not deliberately.
Impact:
- Storage growth is unbounded over time. Probably minor at CTRL's current scale but grows forever.
- Minor data-exposure surface: a DB dump reveals when each user reset their password (userId + timestamp trails), even after the tokens themselves are
used: true and useless for a real reset attempt.
UsersController.resetPasswordinapplication/backend/src/controllers/UsersController.tsmarks a used token viapasswordResetTokenRepo.update({ ..., data: { used: true } })but never deletes the row. Every password reset ever completed sits in thePasswordResetTokentable indefinitely, and there's no scheduled cleanup for used or expired tokens either.Meanwhile, in the same codebase,
AuthController.loginOtpexplicitly deletes the OTP token on use:await prisma.oTPToken.delete({ where: { id: otp.id } }). So there are two auth tokens with two different retention policies in the same file tree, presumably not deliberately.Impact:
used: trueand useless for a real reset attempt.