proposed core.password-reset

Reset a password, the mailbox first, never past another authenticator

A reset asks for an address, or takes the one the sign-in holds. The client must allow the reset flow, on every round, and the request must not ask for a fresh sign-in. The engine mails an 8-digit recovery code through the capped sender, only to an enabled account with a password and a proved address, and asks for it with the same step for every address. A right code proves the mailbox and fixes the account. An account with a passkey or a TOTP proves it next. Then the engine asks for a new password, checks it against the realm's policy and breach list, and in one database transaction replaces the hash, verifies the address, clears the password's disabled mark, revokes every refresh family and advances the session epoch; the user's sessions end, the password's counters clear and the notice is mailed. The reset completes with no amr and no auth_time.

What this view shows

a reset's rounds, from the round that starts it to the password replaced, round by round.

Open world: what is not drawn here is not ruled out. Only the guarantees below are binding.

Left out of this view:

what every round runs before the reset's gate, drawn by flows/core/sign-in: the transaction's checks, the MFA policy, the limiters and the transport's request checks; the bot challenge after the gate; and the end of a transaction that proved an account before that account's last reset (the session epoch)
the sign-in's password step, drawn by flows/core/sign-in: it offers password_reset beside the password while nobody is proved, the reset is allowed and the request asks for no fresh sign-in, and its answer starts this flow with the address it holds
the code's own rules, drawn by flows/core/account-verification: the 10 minutes, the minute before a resend, the email-code ladder across transactions and the burn at the 5th wrong answer of a transaction. A reset's code has 8 digits and goes out before any factor, so it counts toward the send caps' per-address ceiling
the send caps' tiers (#637): which of them answers quietly (the step, the mail dropped) and which answers 429; the mail is dispatched after the answer is built, so sent, dropped and not sent look alike
the other authenticator's own step and ladder, drawn by flows/core/sign-in's rule 8: a passkey's or a TOTP's verification, its throttling and its refusal
ending an unclaimed account (a password and an address never proved) at the first mailbox proof and registering the mailbox owner, PRO-17 (#641): until then this flow treats it as it treats a disabled user
the transport's finish of a reset: it sets no browser session, and the authorization code it mints carries no auth_time and no amr; the consent screen follows as for a sign-in
resolveBrowserSession, which treats a browser session created before the user's session epoch as absent and clears its cookie: Postgres holds the epoch, Redis caches it
a store failure while an audit record is written: the round fails, and the transport answers it as a failed round of its own

The main story

When: The client may run the reset flow, the transport serves password_reset, email_code and new_password, the request carries no max_age and no prompt=login, the send caps let the code through, or drop its mail quietly at the address-and-IP tier, an enabled account holds the address with a password, its address proved, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the reset started on its own, with no address yet.

Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for
Read whether the client may run the reset flow: the client may reset
Go on from where the transaction is: nothing is named yet: the password_reset step, alone
Ask for the address: the person gives an address
Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for
Read whether the client may run the reset flow: the client may reset
Go on from where the transaction is: the round gives the address: it is checked, normalised and kept, and never changes
Read who holds the address, for the mail: the holder is read
Issue an 8-digit recovery code and ask the capped sender to mail it: no account, no password, a disabled user or an unclaimed account: the code is held, nothing is mailed
Ask for the code: the person types the code from the mail
Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for
Read whether the client may run the reset flow: the client may reset
Go on from where the transaction is: the round answers the code with the right one
Compare the right answer with the held code, in constant time: the code is right
Read the address's holder again, before the right code is taken: the code is taken: consumed, email_code joins the verified steps with no amr, the account is fixed
Read the account again, every authenticator included: every authenticator is proved: the new password is asked for
Ask for a new password: the person types a new password
Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for
Read whether the client may run the reset flow: the client may reset
Go on from where the transaction is: the mailbox is proved: the account is read again
Read the account again, every authenticator included: every authenticator is proved, and the round brings a new password
Check the new password against the realm's password policy: the policy accepts it
Check the new password against the realm's breach list: the new password is not on the list, or the realm checks none
Replace the password in one database transaction: the password is replaced, the families revoked and the epoch advanced, all committed together
End the user's sessions and clear the password's counters, then send the notice: the sessions end, the counters clear, the notice is queued, new_password is audited as passed

Result: Complete the reset.

The flow

Show failure paths and “the user closes the page”

blue line: the main storyred dashed line: a failure path (shown with “Show failure paths”)dotted line: decided by a rule, nobody actsdashed grey box: the server decides, nothing is shown

What each step answers

Step	The outside world sees
Ask for the address offeringStart	kind: step · body: {"current":{"step":"password_reset","params":{}},"alternatives":[],"personal":{}}
Ask for the code offeringCode	kind: step · body: {"current":{"step":"email_code","params":{"purpose":"recovery","length":8,"expires_in":"the seconds the code has left, at most 600","resend_after":"the seconds until another code may be asked for, at most 60"}},"alternatives":[],"personal":{"identifier":"the transaction's address"}}
Ask for the code again codeRefused	kind: step · body: {"current":{"step":"email_code","params":{"purpose":"recovery","length":8,"expires_in":"the seconds the code has left, at most 600","resend_after":"the seconds until another code may be asked for, at most 60"},"error":"invalid_credentials"},"alternatives":[],"personal":{"identifier":"the transaction's address"}}
Ask for the account's other authenticator offeringFactor	kind: step · body: {"current":{"step":"the account's webauthn_get or totp step","params":"the step's own"},"alternatives":"the account's other authenticators the transport serves","personal":"the step's own"}
Ask for the other authenticator again factorRefused	kind: step · body: {"current":{"step":"the account's webauthn_get or totp step","params":"the step's own","error":"invalid_credentials"},"alternatives":"the account's other authenticators the transport serves","personal":"the step's own"}
Ask for a new password offeringNewPassword	kind: step · body: {"current":{"step":"new_password","params":{"purpose":"reset","min_length":"the realm's password.minLength","max_length":256}},"alternatives":[],"personal":{"identifier":"the transaction's address"}}
Ask for a new password again newPasswordRefused	kind: step · body: {"current":{"step":"new_password","params":{"purpose":"reset","min_length":"the realm's password.minLength","max_length":256,"reasons":"why the new password was refused"},"error":"password_rejected"},"alternatives":[],"personal":{"identifier":"the transaction's address"}}
Complete the reset recovered	kind: complete · body: {"transaction":null,"subject":"the account's user id","identifier":"the transaction's address, normalised","recovered":true}
Refuse a reset the client may not run resetClosed	kind: refused · body: {"reason":"request_refused","code":"reset_not_allowed"}
Continue elsewhere redirected	kind: redirect · body: {"reason":"step_not_available","transaction":null}
Continue elsewhere, for a request that asks for a fresh sign-in freshSignInRequired	kind: redirect · body: {"reason":"request","transaction":null}
Refuse the round for the send caps sendCapped	kind: refused · body: {"reason":"throttled","retryAfterSeconds":"the send cap's"}
End the transaction for an account disabled or gone accountEnded	kind: refused · body: {"reason":"transaction_ended","transaction":null}
Refuse the round while a store is down unavailable	kind: refused · body: {"reason":"unavailable"}

How it decides what happens next

Ask whether the reset can be served here at all

#	If	Then
1	a step or a port is missing: the engine answers a redirect, and the transaction ends	Continue elsewhere
2	the request asks for a fresh sign-in: the engine answers a redirect, and the transaction ends	Continue elsewhere, for a request that asks for a fresh sign-in
3	every step is served, and no fresh sign-in is asked for	Read whether the client may run the reset flow

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`notServed`	`redirected`	768 of 3648
2	`freshSignIn`	`freshSignInRequired`	384 of 3648
3	otherwise	`readingGate`	2496 of 3648

notServed: not stepsServed

Go on from where the transaction is

#	If	Then
1	the mailbox is proved: the account is read again	Read the account again, every authenticator included
2	the round answers the code with the right one	Compare the right answer with the held code, in constant time
3	the round answers the code with another one	Compare a wrong answer with the held code, in constant time
4	the round asks for a new code, a minute after the last; the count of wrong answers stays	Read who holds the address, for the mail
5	the round carries no answer to the code: the same step, nothing mailed	Ask for the code
6	the transaction holds the address but no code yet: the first code	Read who holds the address, for the mail
7	the round gives the address: it is checked, normalised and kept, and never changes	Read who holds the address, for the mail
8	nothing is named yet: the password_reset step, alone	Ask for the address

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`mailboxProved`	`readingAccount`	576 of 1248
2	`codeHeld and answer == 'rightCode'`	`comparingCode`	96 of 1248
3	`codeHeld and answer == 'wrongCode'`	`comparingWrongCode`	96 of 1248
4	`codeHeld and answer == 'resend'`	`readingMailHolder`	96 of 1248
5	`codeHeld`	`offeringCode`	96 of 1248
6	`addressTaken`	`readingMailHolder`	96 of 1248
7	`answer == 'start'`	`readingMailHolder`	96 of 1248
8	otherwise	`offeringStart`	96 of 1248

Compare the right answer with the held code, in constant time

#	If	Then
1	the code is right	Read the address's holder again, before the right code is taken

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	otherwise	`readingAnswerHolder`	96 of 96

Compare a wrong answer with the held code, in constant time

#	If	Then
1	refused with invalid_credentials, audited as invalid_code	Ask for the code again

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	otherwise	`codeRefused`	96 of 96

Check the new password against the realm's password policy

#	If	Then
1	the policy refuses it: the step again with password_rejected and its reasons	Ask for a new password again
2	the policy accepts it	Check the new password against the realm's breach list

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`newPasswordRejected`	`newPasswordRefused`	8 of 32
2	otherwise	`checkingNewBreachList`	24 of 32

newPasswordRejected: newPassword == 'rejected'

Every way it can end

It ends with	When	What happens
Complete the reset ends here	The client may run the reset flow, the transport serves password_reset, email_code and new_password, the request carries no max_age and no prompt=login, the send caps let the code through, or drop its mail quietly at the address-and-IP tier, no account of the realm holds the address with a password, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the sign-in's password step started it, with the address it held	Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may reset Go on from where the transaction is: the transaction holds the address but no code yet: the first code Read who holds the address, for the mail: the holder is read Issue an 8-digit recovery code and ask the capped sender to mail it: no account, no password, a disabled user or an unclaimed account: the code is held, nothing is mailed Ask for the code: the person types the code from the mail Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may reset Go on from where the transaction is: the round answers the code with the right one Compare the right answer with the held code, in constant time: the code is right Read the address's holder again, before the right code is taken: the code is taken: consumed, email_code joins the verified steps with no amr, the account is fixed Read the account again, every authenticator included: every authenticator is proved: the new password is asked for Ask for a new password: the person types a new password Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may reset Go on from where the transaction is: the mailbox is proved: the account is read again Read the account again, every authenticator included: every authenticator is proved, and the round brings a new password Check the new password against the realm's password policy: the policy accepts it Check the new password against the realm's breach list: the new password is not on the list, or the realm checks none Replace the password in one database transaction: the password is replaced, the families revoked and the epoch advanced, all committed together End the user's sessions and clear the password's counters, then send the notice: the sessions end, the counters clear, the notice is queued, new_password is audited as passed
Refuse a reset the client may not run ends here	The client is gone, disabled or suspended, or its policy does not list the reset flow, the transport serves password_reset, email_code and new_password, the request carries no max_age and no prompt=login, the send caps let the code through, or drop its mail quietly at the address-and-IP tier, no account of the realm holds the address with a password, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the reset started on its own, with no address yet	Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may not reset: refused, audited as reset_closed
Continue elsewhere ends here	The client is gone, disabled or suspended, or its policy does not list the reset flow, the transport cannot serve password_reset, email_code or new_password, or the engine lacks the ports, the request carries no max_age and no prompt=login, the send caps let the code through, or drop its mail quietly at the address-and-IP tier, no account of the realm holds the address with a password, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the reset started on its own, with no address yet	Ask whether the reset can be served here at all: a step or a port is missing: the engine answers a redirect, and the transaction ends
Continue elsewhere, for a request that asks for a fresh sign-in ends here	The client is gone, disabled or suspended, or its policy does not list the reset flow, the transport serves password_reset, email_code and new_password, the request carries max_age or prompt=login, the send caps let the code through, or drop its mail quietly at the address-and-IP tier, no account of the realm holds the address with a password, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the reset started on its own, with no address yet	Ask whether the reset can be served here at all: the request asks for a fresh sign-in: the engine answers a redirect, and the transaction ends
Refuse the round for the send caps ends here	The client may run the reset flow, the transport serves password_reset, email_code and new_password, the request carries no max_age and no prompt=login, a tier that answers 429 is full, no account of the realm holds the address with a password, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the sign-in's password step started it, with the address it held	Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may reset Go on from where the transaction is: the transaction holds the address but no code yet: the first code Read who holds the address, for the mail: the holder is read Issue an 8-digit recovery code and ask the capped sender to mail it: a tier that answers 429 is full: nothing is mailed or kept, send_capped is audited
End the transaction for an account disabled or gone ends here	The client may run the reset flow, the transport serves password_reset, email_code and new_password, the request carries no max_age and no prompt=login, the send caps let the code through, or drop its mail quietly at the address-and-IP tier, no account of the realm holds the address with a password, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the sign-in's password step started it, with the address it held	Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may reset Go on from where the transaction is: the transaction holds the address but no code yet: the first code Read who holds the address, for the mail: the holder is read Issue an 8-digit recovery code and ask the capped sender to mail it: no account, no password, a disabled user or an unclaimed account: the code is held, nothing is mailed Ask for the code: the person types the code from the mail Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may reset Go on from where the transaction is: the round answers the code with the right one Compare the right answer with the held code, in constant time: the code is right Read the address's holder again, before the right code is taken: the code is taken: consumed, email_code joins the verified steps with no amr, the account is fixed Read the account again, every authenticator included: every authenticator is proved: the new password is asked for Ask for a new password: the next round carries no answer: the same step Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: the client may reset Go on from where the transaction is: the mailbox is proved: the account is read again Read the account again, every authenticator included: the account is disabled or gone: the transaction ends, audited, nothing written
Refuse the round while a store is down ends here	The client is gone, disabled or suspended, or its policy does not list the reset flow, the transport serves password_reset, email_code and new_password, the request carries no max_age and no prompt=login, the send caps let the code through, or drop its mail quietly at the address-and-IP tier, no account of the realm holds the address with a password, the account holds no passkey and no TOTP, the policy accepts it, and the realm's breach list does not hold it or the realm checks none, the reset started on its own, with no address yet	Ask whether the reset can be served here at all: every step is served, and no fresh sign-in is asked for Read whether the client may run the reset flow: it fails, because the client cannot be read

Each row is also a generated test: set the starting situation, send the events, expect the ending.

What is guaranteed

These hold in all 15316 situations the model can reach, from 1536 different starting situations.

No reset step is offered, nothing is mailed and nothing is written unless the client may reset
A request that carries max_age or prompt=login is never reset
Nothing is written before the mailbox is proved
An account with a passkey or a TOTP never resets with its mailbox alone
No password is replaced before the new one passes the realm's policy and breach list
Only an enabled account with a password and a proved address is mailed a code; a disabled user, an unclaimed account and an unknown address get nothing
A disabled user is never reset
A completed reset revoked every refresh family, advanced the epoch and queued the notice
A reset never clears a second factor's counter or disabled mark
A reset issues no amr value and no auth_time
A code is compared only once the transaction holds the address it went to
Every refused answer and the completed reset write an audit record
Every round that ends here answers no earlier than 500 ms after it arrived, so an existing address and an unknown one take the same time

Exact rules

Id	Never
`nothing-before-the-gate`	`state in ['offeringStart', 'offeringCode', 'codeRefused', 'offeringFactor', 'factorRefused', 'offeringNewPassword', 'newPasswordRefused', 'recovered', 'sendCapped'] and not resetAllows`
`never-under-a-fresh-sign-in`	`state in ['offeringStart', 'offeringCode', 'codeRefused', 'offeringFactor', 'factorRefused', 'offeringNewPassword', 'newPasswordRefused', 'recovered'] and freshSignIn`
`no-change-before-the-mailbox`	`passwordReplaced and not mailboxProved`
`email-never-stands-in`	`passwordReplaced and otherFactor != 'none' and not factorProved`
`no-change-before-the-password`	`passwordReplaced and not passwordAccepted`
`only-an-enabled-account-is-mailed`	`mailQueued and holder != 'enabled'`
`a-disabled-user-is-never-changed`	`state == 'recovered' and holder != 'enabled'`
`the-reset-ends-what-the-old-password-opened`	`state == 'recovered' and not (familiesRevoked and epochAdvanced and noticeQueued)`
`a-second-factor-is-never-touched`	`secondFactorTouched`
`no-factor-at-reset`	`factorClaimed`
`compare-only-a-held-code`	`codeCompared and not addressTaken`
`every-refusal-is-audited`	`state in ['resetClosed', 'sendCapped', 'codeRefused', 'factorRefused', 'newPasswordRefused', 'accountEnded', 'recovered'] and not audited`
`every-round-waits-the-floor`	`state in ['offeringStart', 'offeringCode', 'codeRefused', 'offeringFactor', 'factorRefused', 'offeringNewPassword', 'newPasswordRefused', 'recovered', 'resetClosed', 'redirected', 'freshSignInRequired', 'sendCapped', 'accountEnded', 'unavailable'] and not floorWaited`

Reference

All transitions (65)

From	Event	Guard	To	Effects	Taken
`checkingSteps`	`rule 1`	`notServed`	`redirected`	`waitFloor`	yes
`checkingSteps`	`rule 2`	`freshSignIn`	`freshSignInRequired`	`waitFloor`	yes
`checkingSteps`	`rule 3`		`readingGate`		yes
`readingGate`	`DONE`	`closed`	`resetClosed`	`audit` `waitFloor`	yes
`readingGate`	`DONE`		`dispatching`		yes
`readingGate`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`dispatching`	`rule 1`	`mailboxProved`	`readingAccount`		yes
`dispatching`	`rule 2`	`codeHeld and answer == 'rightCode'`	`comparingCode`		yes
`dispatching`	`rule 3`	`codeHeld and answer == 'wrongCode'`	`comparingWrongCode`		yes
`dispatching`	`rule 4`	`codeHeld and answer == 'resend'`	`readingMailHolder`		yes
`dispatching`	`rule 5`	`codeHeld`	`offeringCode`	`waitFloor`	yes
`dispatching`	`rule 6`	`addressTaken`	`readingMailHolder`		yes
`dispatching`	`rule 7`	`answer == 'start'`	`readingMailHolder`	`takeAddress`	yes
`dispatching`	`rule 8`		`offeringStart`	`waitFloor`	yes
`readingMailHolder`	`DONE`		`issuingCode`		yes
`readingMailHolder`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`issuingCode`	`DONE`	`capped`	`sendCapped`	`audit` `waitFloor`	yes
`issuingCode`	`DONE`	`mailable`	`offeringCode`	`holdCode` `queueCodeMail` `waitFloor`	yes
`issuingCode`	`DONE`	`notMailable`	`offeringCode`	`holdCode` `waitFloor`	yes
`issuingCode`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`comparingCode`	`rule 1`		`readingAnswerHolder`	`compareCode`	yes
`comparingWrongCode`	`rule 1`		`codeRefused`	`compareCode` `audit` `waitFloor`	yes
`readingAnswerHolder`	`DONE`	`notMailable`	`codeRefused`	`audit` `waitFloor`	yes
`readingAnswerHolder`	`DONE`		`readingAccount`	`proveMailbox` `audit`	yes
`readingAnswerHolder`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`readingAccount`	`DONE`	`notMailable`	`accountEnded`	`audit` `waitFloor`	yes
`readingAccount`	`DONE`	`factorPending and otherFactor == 'unusable'`	`redirected`	`waitFloor`	yes
`readingAccount`	`DONE`	`factorPending and answer in ['rightFactor', 'wrongFactor']`	`verifyingFactor`		yes
`readingAccount`	`DONE`	`factorPending`	`offeringFactor`	`waitFloor`	yes
`readingAccount`	`DONE`	`answer == 'newPassword'`	`checkingNewPassword`		yes
`readingAccount`	`DONE`		`offeringNewPassword`	`waitFloor`	yes
`readingAccount`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`verifyingFactor`	`DONE`	`answer == 'wrongFactor'`	`factorRefused`	`audit` `waitFloor`	yes
`verifyingFactor`	`DONE`		`offeringNewPassword`	`proveFactor` `audit` `waitFloor`	yes
`verifyingFactor`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`checkingNewPassword`	`rule 1`	`newPasswordRejected`	`newPasswordRefused`	`audit` `waitFloor`	yes
`checkingNewPassword`	`rule 2`		`checkingNewBreachList`		yes
`checkingNewBreachList`	`DONE`	`newPasswordListed`	`newPasswordRefused`	`audit` `waitFloor`	yes
`checkingNewBreachList`	`DONE`	`newPassword == 'accepted'`	`resetting`	`acceptPassword`	yes
`checkingNewBreachList`	`FAIL.lookup`	`newPassword == 'checkFailed'`	`resetting`	`acceptPassword` `recordBreachFailure`	yes
`resetting`	`DONE`	`notMailable`	`accountEnded`	`audit` `waitFloor`	never
`resetting`	`DONE`		`endingSessions`	`replacePassword`	yes
`resetting`	`FAIL.store`		`unavailable`	`waitFloor`	yes
`endingSessions`	`DONE`		`recovered`	`endSessions` `queueNotice` `audit` `waitFloor`	yes
`endingSessions`	`FAIL.store`		`recovered`	`queueNotice` `audit` `waitFloor`	yes
`offeringStart`	`ROUND`		`checkingSteps`	`newRound` `moveOn`	yes
`offeringStart`	`START`		`checkingSteps`	`newRound` `moveOn` `answerStart`	yes
`offeringCode`	`ROUND`		`checkingSteps`	`newRound` `moveOn`	yes
`offeringCode`	`RIGHT_CODE`		`checkingSteps`	`newRound` `moveOn` `answerRight`	yes
`offeringCode`	`WRONG_CODE`		`checkingSteps`	`newRound` `moveOn` `answerWrong`	yes
`offeringCode`	`RESEND`		`checkingSteps`	`newRound` `moveOn` `answerResend`	yes
`codeRefused`	`ROUND`		`checkingSteps`	`newRound` `moveOn`	yes
`codeRefused`	`RIGHT_CODE`		`checkingSteps`	`newRound` `moveOn` `answerRight`	yes
`codeRefused`	`WRONG_CODE`		`checkingSteps`	`newRound` `moveOn` `answerWrong`	yes
`codeRefused`	`RESEND`		`checkingSteps`	`newRound` `moveOn` `answerResend`	yes
`offeringFactor`	`ROUND`		`checkingSteps`	`newRound` `moveOn`	yes
`offeringFactor`	`RIGHT_FACTOR`		`checkingSteps`	`newRound` `moveOn` `answerRightFactor`	yes
`offeringFactor`	`WRONG_FACTOR`		`checkingSteps`	`newRound` `moveOn` `answerWrongFactor`	yes
`factorRefused`	`ROUND`		`checkingSteps`	`newRound` `moveOn`	yes
`factorRefused`	`RIGHT_FACTOR`		`checkingSteps`	`newRound` `moveOn` `answerRightFactor`	yes
`factorRefused`	`WRONG_FACTOR`		`checkingSteps`	`newRound` `moveOn` `answerWrongFactor`	yes
`offeringNewPassword`	`ROUND`		`checkingSteps`	`newRound` `moveOn`	yes
`offeringNewPassword`	`NEW_PASSWORD`		`checkingSteps`	`newRound` `moveOn` `answerNewPassword`	yes
`newPasswordRefused`	`ROUND`		`checkingSteps`	`newRound` `moveOn`	yes
`newPasswordRefused`	`NEW_PASSWORD`		`checkingSteps`	`newRound` `moveOn` `answerNewPassword`	yes