Authorization Bypass Through User-Controlled Key vulnerability in team-alembic ash_authentication allows a user with an account to install a TOTP secret they control on another user's account, and then sign in as that user or hold their second factor.
AshAuthentication.Strategy.Totp.ConfirmSetupChange verified a setup token but did not check that it was issued to the record being confirmed, so an attacker's own pending secret could be confirmed onto another user's record. The TOTP setup changes, ConfirmSetupChange, GeneratePendingSetupChange and GenerateSecretChange, also marked their changesets as AshAuthentication interactions, which the standard AshAuthenticationInteraction policy bypass lets through. A policy limiting setup and confirm_setup to the actor's own record therefore never ran when an application exposed those actions by record key, and a direct setup call on another user's record returned that user's pending secret and setup token.
This issue affects ash_authentication: from 5.0.0-rc.0 before 5.0.0-rc.16.
An application exposes the TOTP setup or confirm_setup action on a record the caller identifies, for example through AshJsonApi, AshGraphql or a controller that passes a looked-up user to AshAuthentication.Strategy.Totp.Actions.confirm_setup/3, and the attacker can read the victim's user record. Installing the attacker's secret requires confirm_setup_enabled? true; signing in with it alone requires sign_in_enabled? true. The routes AshAuthentication and AshAuthenticationPhoenix provide always use the signed-in user and are not affected.
Do not expose setup or confirm_setup on a record the caller chooses. Call them through AshAuthentication.Strategy.Totp.Actions with the signed-in user, as the built-in routes do.