Page MenuHomePhabricator

Carry MFA responses which have been "answered" but not "completed" through the MFA workflow

Authored by epriestley on Dec 17 2018, 7:12 PM.



Depends on D19894. Ref T13222. See PHI873. When you provide a correct response to an MFA challenge, we mark it as "answered".

Currently, we never let you reuse an "answered" token. That's usually fine, but if you have 2+ factors on your account and get one or more (but fewer than all of them) right when you submit the form, you need to answer them all again, possibly after waiting for a lockout period. This is needless.

When you answer a challenge correctly, add a hidden input with a code proving you got it right so you don't need to provide another answer for a little while.

Why not just put your response in a form input, e.g. <input type="hidden" name="totp-response" value="123456" />?

  • We may allow the "answered" response to be valid for a different amount of time than the actual answer. For TOTP, we currently allow a response to remain valid for 60 seconds, but the actual code you entered might expire sooner.
  • In some cases, there's no response we can provide (with push + approve MFA, you don't enter a code, you just tap "yes, allow this" on your phone). Conceivably, we may not be able to re-verify a push+approve code if the remote implements one-shot answers.
  • The "responseToken" stuff may end up embedded in normal forms in some cases in the future, and this approach just generally reduces the amount of plaintext MFA we have floating around.
Test Plan
  • Added 2 MFA tokens to my account.
  • Hit the MFA prompt.
  • Provided one good response and one bad response.
  • Submitted the form.
  • Old behavior: good response gets locked out for ~120 seconds.
  • New behavior: good response is marked "answered", fixing the other response lets me submit the form.

Diff Detail

rP Phabricator
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.