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)
Sat, May 4, 6:59 PM
Unknown Object (File)
Thu, May 2, 3:46 AM
Unknown Object (File)
Wed, May 1, 12:28 AM
Unknown Object (File)
Mon, Apr 29, 6:22 PM
Unknown Object (File)
Tue, Apr 23, 6:47 PM
Unknown Object (File)
Tue, Apr 23, 6:47 PM
Unknown Object (File)
Fri, Apr 19, 8:45 AM
Unknown Object (File)
Thu, Apr 11, 9:53 AM
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
Branch
mfa6
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 21333
Build 29031: Run Core Tests
Build 29030: arc lint + arc unit

Event Timeline

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

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–511

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.