Suppress user-interactive authentication after login

[benparsons]

When creating a new account via SSO: once users reach the web interface users should not be shown a modal asking to connect to SSO, and should not be shown a new window at ../m.sso.fallback/...

cc @lampholder @clokep

[richvdh]

This sounds like my ballpark, but I'm not entirely sure what you mean here. can you share screenshots or something to help me understand what's going on?

[clokep]

I had a call with @benparsons about this yesterday, the conversation got a bit confusing. There's been multiple requests from customers to not show the user-interactive authentication confirmation screens when using SSO. I requested that Ben file an issue for discussion. It might be reasonable to add a config option to disable them, but it might not be so I'm hoping we can either result in:

• Some improvement here for people who might be OK with the security ramifications of removing this, or
• A more succinct explanation of why we cannot do this.

There was some thoughts that having the access_token for an SSO account isn't potentially not that destructive, the malicious attacker could only:

• Log the user out (but since it is SSO they can always log back in). (This has some assumptions that the user doesn't also have a password / password logins & reset are disabled and such.)
• Change the key backup information (locking the user out of their old encrypted messages).

@lampholder hopefully I described that correctly, but please expand if not.

Some background about why this confirmation is important:

• Spec for SSO + UIA has a security considerations section:

1. Confirming the operation

   The homeserver SHOULD confirm that the user is happy for the operation to go ahead. The goal of the user-interactive authentication operation is to guard against a compromised access_token being used to take over the user's account. Simply redirecting the user to the SSO system is insufficient, since they may not realise what is being asked of them, or the SSO system may even confirm the authentication automatically.

For example, the homeserver might serve a page with words to the effect of:

A client is trying to remove a device from your account. To confirm this action, re-authenticate with single sign-on. If you did not expect this, your account may be compromised!

This confirmation could take place before redirecting to the SSO authentication page (when handling the /_matrix/client/r0/auth/m.login.sso/fallback/web endpoint), or after authentication when handling the callback from the authentication server. (If the check is performed before redirecting, it is particularly important that the homeserver guards against unsolicited authentication attempts as below).

2. For added security, homeservers SHOULD guard against unsolicited authentication attempts by tracking pending requests. One way to do this is to set a cookie when handling /_matrix/client/r0/auth/m.login.sso/fallback/web, which is checked and cleared when handling the callback from the authentication server.

• MSC2454 also has some information about this.

[clokep]

Note that the same approach as removing this page for login cannot be used. That depends on the sso.client_whitelist option which filters where the redirect the client back to after SSO is complete. For UI auth there is no redirect back to the client, so nothing to filter on.

[clokep]

After a bit more back and forth this is due to a particular workflow where an operation requiring UI auth is done right after login.

A potential solution to this that was floated is to not require UI auth within some amount of time of login. (A variation of that is to not tie it into login and to give a timeout on any authentication.) Where "some amount of time" is short (minutes).

[erikjohnston]

A potential solution to this that was floated is to not require UI auth within some amount of time of login. (A variation of that is to not tie it into login and to give a timeout on any authentication.) Where "some amount of time" is short (minutes).

I think we need to be a little bit careful here so as not to introduce security holes, e.g. remembering authorisation for 5 mins means that the app is vulnerable for those 5 mins to the attack that UIA is designed to mitigate.

Registration/login is at least less common, though ideally we'd try and make this an explicit thing where apps can purposefully stay authenticated for a bit (e.g. use the same token and then drop it when they're done with the operations).

I'm not massively against this idea, but without putting much thought into it it makes my spider sense tingle slightly.

[clokep]

I think we need to be a little bit careful here so as not to introduce security holes, e.g. remembering authorisation for 5 mins means that the app is vulnerable for those 5 mins to the attack that UIA is designed to mitigate.

I agree, it is a tradeoff of security and usability though. A couple of ideas of how this could be done:

• Add a last_authenticated to the access_tokens table.
• Add a config option authentication_timeout (or something) which defaults to 0, but is the number of seconds to keep an authentication session "live".
• When a user logs in or completes UI auth, update last_authenticated for that access token.
• When the user attempts to do UI auth (and authentication_timeout is enabled) then short-circuit and check if they're already authenticated.

Another option might be to tie this into UI auth sessions with similar logic to the above, but I'm having trouble figuring out if this could work with login -> UI auth. The benefit of using the sessions is that we could add an endpoint to "cancel" a session which would give clients control of when to drop UI authed power.

Both of these do break UI auth though since UI auth sessions are currently meant to be tied to a single operation. I.e. they're purposefully not allowed to be re-used. The particular issue of doing things just after login feels a little bit more palatable, I think.