Page MenuHomePhabricator

Remove the requirement to enter a password during the login flow
Open, Needs TriagePublic

Description

At the moment the login page of MediaWiki, in the default configuration, requires the user to type in their username and their password in order to be able to click the login button (which should be the main confirmation element of this form). This, however, limits the possible authentication credentials to be a set of username and password. It prevents extensions to provide an AuthenticationProvider which adds additional ways to prove the identity of a user, when the extension is based on the username. For example the Passwordless Login extension[1] (done through the Wikimedia-Hackathon-2019) requires the user to type in their username but not the password, as the identity will (in a second UI step) be proved by a second factor (smartphone login prompt).

There may also be other possible login mechanisms, which require the user to type in their username but not their password.

This task does not exactly propose a way to solve it (however I'll post three possible solutions from my point of view) but should be here to discuss how this could be solved, in order to find a suitable solution.

The problem (the required password field) could be solved in these ways, from my point of view:

  1. Removing the "required" attribute from the password field

-> This is probably one of the worst solutions, as there's no clear indication for the user that the field is not requires, when they should fill it out and when not. I would consider this bad UI/UX for the user during the login flow, however, it would be the easiest implementation I think.

  1. The password field is removed from the initial Login form. If the user entered their username, they can just click on "Continue" (not Login anymore) and the AuthManager will check all available PrimaryAuthenticationProviders about their AuthenticationResponse. If multiple providers respond with a new UI, the provider with the highest priority will win (this could also be the PasswordAuthenticationProvider). The user then does whatever the UI says (e.g. type in their password or verify the login on the smartphone) and continues with the login process then. Additionally, if more than one provider answered with a new UI, the user probably sees a list of links where they can switch to another authentication mechanism (e.g. switch from Passwordless Login to the password login).

-> This would be the biggest user-facing change I think. It would completely chnage the login flow, breaks any password manager auto-fill option, if I'm not mistaken, and will require more steps in the login flow for the users. However, I think this would be one of the "cleanest" implementations.

  1. This would be a mixed version of 2. Anything of 2 would be implemented, but behind a feature flag. That means, that the MediaWiki site-admin would need to set a configuration option in order to enable it and they can decide if it does make sense to do so, e.g. when they installed an extension liked Passwordless Login.

Let's discuss about that and probably there're other ideas about how this could be solved, too :)

[1] T220418: Passwordless login (login with your smartphone)

Event Timeline

I played a bit with the first solution, however, it turns out that, even if we move the password field into a second step (which would mean, that the AbstractPasswordPrimaryAuthenticationProvider needs to return a UI AuthenticationResponse in the beginPrimaryAuthentication step), there's the problem thet AuthManager requires a response from continuePrimaryAuthentication to be non-ABSTAIN (which makes kind of sense). However, this means, that there can only be one password authentication provider listening for the second, new, UI step, however, core ships with 2 already (temporary and local passwords).

So, question into the round: What are the problems with making an ABSTAIN response valid in a continue authentication step?

So, question into the round: What are the problems with making an ABSTAIN response valid in a continue authentication step?

There can be only one PrimaryAuthenticationProvider that handles the request, chosen as the first one that returns a non-ABSTAIN. If a Primary can first claim it but then "unclaim" it, how does the login flow continue from there? Even if the user starts over from the beginning, how do we make sure they don't wind up at the same dead end?

  1. Removing the "required" attribute from the password field

This already happens when some Primary returns an AuthenticationRequest that doesn't include a password field. You're right that it isn't terribly clear which fields are needed when in that case.

  1. The password field is removed from the initial Login form. If the user entered their username, they can just click on "Continue" (not Login anymore) and the AuthManager will check all available PrimaryAuthenticationProviders about their AuthenticationResponse.

It seems like you're trying to get at two things here:

  • The user selects which method (out of all available methods) they want to use to log in, before being presented with the form fields relevant to that method.
  • PrimaryAuthenticationProviders would use the username to determine whether they should be considered "available" for the particular user (e.g. if the user has no phone paired, PasswordlessLogin wouldn't show up).

The second bullet might be considered an info leak, it should be run by Security. The first bullet isn't a bad idea, IMO, but probably needs someone with real UI/UX experience (i.e. not me) to design it after being provided an analysis of the technical constraints.

If we skip the second bullet we may be able to avoid more page-loads for JS-enabled clients, although there would still be an extra "step" in selecting between available methods. Non-JS clients would probably need an extra page load for the same UX, but it might be possible to have a UX that lists the methods in sections so the user can simply page down to the appropriate section.