Page MenuHomePhabricator

Allow a challenge stage during authentication
Closed, ResolvedPublic

Description

Extension:OATHAuth implements two-factor authentication, and requires a token for users during the login process, if they have two-factor enabled. Unfortunately, it's necessary to put a token input on the initial login page, which is confusing for users who don't have two-factor enabled, or don't know what it is.

The proper solution for this is to have a challenge screen after the initial password login. MediaWiki doesn't have support for this. An extension can't display another screen before the authentication step completes, and once the authentication step completes, the user is logged in.


Version: 1.22.0
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42131

Details

Reference
bz46179

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:20 AM
bzimport set Reference to bz46179.
bzimport added a subscriber: Unknown Object (MLST).

I'm adding bug 42131 as a see also (and leaving it marked resolved/wontfix), but it may properly be a dependency of this bug.

Just to document the problem with this right now, here is the current workflow:

  1. Do preliminary login checks
  2. Run AbortLogin hook
  3. Check password
  4. Log in the user

All extensions are forced to hook in at step 2, which is before the password check. So if an extension needs to gather more information, and it redirects to another page, the password check has never happened and the password itself is no longer in the request.

Right now in OATHAuth, I'm getting around this by taking the WebRequest, storing it, and basically replaying the request once the new information is gathered. Of course, this is a risk because now private information is stored in Memcached. This can be mitigated with some sort of symmetric encryption, but it'd be better to just avoid it entirely.

The preferred workflow would be to have AuthManager organize its checks and be able to store the results of those checks so that further information can be gathered and further checks can be performed before the user is determined to be authenticated.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 26 2015, 4:40 AM
Tgr added a subscriber: Tgr.Aug 26 2015, 4:45 AM

In AuthManager SecondaryAuthenticationProviders fulfill this role: they are invoked after the identity of the user has been established, can request further information (which will be handled by Special:UserLogin by showing a second form after the normal login form), and can block or abort the authentication process based on the reply.

Anomie closed this task as Resolved.Jun 16 2016, 4:27 PM
Anomie claimed this task.
Anomie added a subscriber: Anomie.

AuthManager does this with SecondaryAuthenticationProviders. Further, OATHAuth has been updated to use this mechanism for its challenges in rEOAT563796a98c05: Update for AuthManager.