Interactive auth chooses the first flow it sees, not the one it supports

[spantaleev]

Steps to reproduce

1. Add at least one password provider module to Synapse which supports a custom login type (an example is matrix-synapse-shared-secret-auth, which defines a com.devture.shared_secret_auth login type meant to be used like this). You don't even need to use the custom password provider - it just needs to be registered with Synapse. You can also register a custom module providing a my.login_type like this example in the Synapse docs
2. Use Element and try to delete one of your existing devices from the Security & Privacy dialog
3. An Authentication popup appears with a Start authentication button
4. Clicking Start authentication leads to https://matrix.DOMAIN/_matrix/client/r0/auth/com.devture.shared_secret_auth/fallback/web?session=.... (note the com.devture.shared_secret_auth part of the URL)
5. This page renders: {"errcode":"M_UNKNOWN","error":"Unknown auth stage type"} and you can't proceed

Outcome

What did you expect?

I expect interactive auth to work using a supported authentication method (m.login.password, etc.), despite various password provider modules advertising other (unknown to Element) login methods.

What happened instead?

Upon pressing the Delete devices button in Element, a Request to POST /_matrix/client/r0/delete_devices got sent, which received a response like this:

{
    "session":"...",
    "flows":[
        {"stages":["com.devture.shared_secret_auth"]},
        {"stages":["m.login.password"]}
    ],
    "params":{}
}

It seems like Element picked the first flow it saw (com.devture.shared_secret_auth in this case), instead of the flow it understands.

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

1.9.3

Homeserver

No response

Will you send logs?

No

[spantaleev]

Right now (Synapse v1.53.0), I'm seeing the opposite.

The m.login.password flow is first in the flows list reported by POST /_matrix/client/r0/delete_devices, which effectively works around this problem.

Perhaps something changed in recent Synapse versions, which fixed this problem (by coincidence or not)?

[Sharparam]

As of Synapse v1.55.0 the ordering seems to have changed back to the problematic one again, see my comment here for context: devture/matrix-synapse-shared-secret-auth#12 (comment)

Edit: As far as I can tell, this is also an issue on Element Android. Does an issue need to be created there as well? (If it gets fixed in Element Web, it's easy enough to just do device removals there, but getting it fixed everywhere is probably best.)

[waclaw66]

It's probably because order of flows is random...
https://github.com/matrix-org/synapse/blob/e78d4f61fc881851ab35e9a889239a61cf9805e5/synapse/handlers/auth.py#L390

EDIT: it works when I changed set() to a list

[turbotorsten]

I got a matrix error changig the set to a list, but just commenting out the password provider and sso below the line you mentioned allowed me to sign out devices, as after that element brought the password prompt up as it should.

[MichaelSasser]

I have the same problem with UIAA on Synapse v1.64.0 and earlier. SSO users are being asked to enter a password m.login.password even though they don't have any (the m.login.sso stage should have been picked instead).

In my case, the m.login.password stage comes from devture/matrix-synapse-shared-secret-auth (matrix_synapse_ext_password_provider_shared_secret_auth_enabled and matrix_synapse_ext_password_provider_shared_secret_auth_m_login_password_support_enabled are true in the playbook).
When I disable the external password provider, the m.login.password stage is removed (Active flow => {"stages":["m.login.sso"]} is left) and users can confirm their identity.

This happens to users, who were migrated from LDAP and freshly created ones (SSO). When an external password provider is used or needed for whatever reason and users cannot sign out devices, this is a security risk.

[t3chguy]

@MichaelSasser that is not this issue, the server should not be asking the user to fulfil a flow they do not have means to. Fixing this issue would be a work-around, not a fix. The server should only offer password flows to users with a set password.

[spantaleev]

So, we need to add some mechanism by which Synapse's auth provider modules can say whether a given auth flow should be available for a given mxid?

[t3chguy]

Correct. UIA is an authenticated flow, so the presented flows should be sculpted to the requester. https://spec.matrix.org/v1.3/client-server-api/#user-interactive-authentication-api

For each endpoint, a server offers one or more ‘flows’ that the client can use to authenticate itself. Each flow comprises a series of stages, as described above. The client is free to choose which flow it follows

[spantaleev]

It'd be great if we can make the homeserver not present these flows to certain users (or to all users even) when dealing with "interactive" authentication.

---

Still, this part makes me think that the client is also advised to choose a flow more wisely:

The client is free to choose which flow it follows

Choosing the first flow that it sees (and more importantly, a flow that it doesn't understand how to handle) doesn't sound ideal, hence this issue here.

[t3chguy]

and more importantly, a flow that it doesn't understand how to handle

In the example above you said m.login.password + m.login.sso - Element can handle both of those, the issue being that the user cannot fulfil m.login.password.

Yes this issue is kept open because the client should be more wise, but equally so should the server and any plugins/modules.

[MichaelSasser]

Oh, ok. I was assuming, there was some communication beforehand, I missed, where the server must have communicated to the client, which auth types the user can fulfil, based on the two flows (password and sso in my case) the client got from the server when I bootstrap cross signing for example. Otherwise, it wouldn't make sense for the server to include a m.login.password flow in an SSO situation.

So, if I understand it correctly now, when a hs is configured to support idk password, msisdn and email identity, but the user can only fulfil password, and email identity, the server should only give the client flows which can contain those two auth types. The client then chooses one of the flows, it supports, but the choosing part itself is an implementation detail.

In this case, I would prefer, if Element, as an interactive client, lets users select the preferred flow from the ones, both (server and client) support, over picking one for them. This would not only mitigate the current situation, where Element receives a and chooses a flow, that might be impossible for the user to fulfil, but also brings some comfort for the user. I think of a situation, where element might decide msisdn (if it supports it) and the phone is somewhere downstairs charging. In this case, password might have been a more convenient choice.

[t3chguy]

There is no communication beforehand, each UIA response contains the possible flows a user/client can take to auth the request.

but the choosing part itself is an implementation detail.

Yes, ideally the client is smart enough to exclude any flows it cannot fulfil due to lack of implementation and present the user all other possible flows, though that is a bit trickier.

In this case, I would prefer, if Element, as an interactive client, lets users select the preferred flow from the ones, both (server and client) support, over picking one for them.

This is the likely solution to this issue, though will require design input on how the UX for this would look.