Page MenuHomePhabricator

Require MFA implementations to return a formal result object when validating factors
ClosedPublic

Authored by epriestley on Dec 13 2018, 8:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 10 2024, 9:32 AM
Unknown Object (File)
Feb 3 2024, 8:16 PM
Unknown Object (File)
Dec 27 2023, 12:58 PM
Unknown Object (File)
Dec 22 2023, 12:59 AM
Unknown Object (File)
Dec 20 2023, 5:30 PM
Unknown Object (File)
Dec 13 2023, 7:15 PM
Unknown Object (File)
Nov 30 2023, 1:32 AM
Unknown Object (File)
Nov 15 2023, 4:31 PM
Subscribers
None

Details

Summary

Ref T13222. See PHI873. Currently, MFA implementations return this weird sort of ad-hoc dictionary from validation, which is later used to render form/control stuff.

I want to make this more formal to handle token reuse / session binding cases, and let MFA factors share more code around challenges. Formalize this into a proper object instead of an ad-hoc bundle of properties.

Test Plan
  • Answered a TOTP MFA prompt wrong (nothing, bad value).
  • Answered a TOTP MFA prompt properly.
  • Added new TOTP MFA, survived enrollment.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

amckinley added inline comments.
src/applications/auth/engine/PhabricatorAuthSessionEngine.php
504–514

Does this type checking live here because someone might have added their own implementation of PhabricatorAuthFactor?

src/applications/auth/factor/PhabricatorTOTPAuthFactor.php
174

I'm assuming this was intentional, and that PhabricatorAuthFactorResult.hint is really more of an error-hint.

This revision is now accepted and ready to land.Dec 13 2018, 9:17 PM
src/applications/auth/engine/PhabricatorAuthSessionEngine.php
504–514

Yeah, this is just a guard rail in case someone has another MFA implementation somewhere that's expecting it can return a string or a picture of a dog or something.

src/applications/auth/factor/PhabricatorTOTPAuthFactor.php
174

"Hint" may not be the best name, but I'm trying to distinguish between "hint next to the input about what's wrong with the thing you input" and "big error message in a banner". Not 100% sure where things are headed yet so this might change. If I don't need both, I'll likely change this to setError(...).

D19886 ended up renaming "Hint" to "Error Message" and pushing the instanceof X logic into the abstract base AuthFactor class, using this sorta thing:

final public function getX() {
  $x = $this->newX();
  if ($x is bad) { cry };
  return $x;
}

abstract protected function newX();

...since that seemed cleaner by the time I got things working.

This revision was automatically updated to reflect the committed changes.