MSC4108: Mechanism to allow OIDC sign in and E2EE set up via QR code

[hughns]

Rendered

Dependencies:

• MSC3861: Next-generation auth for Matrix, based on OAuth 2.0/OIDC #3861

Implementations:

• Homeservers
  • Synapse
    • Support for MSC3861
    • Support for MSC4108 delegation to external server: Support for MSC4108 via delegation element-hq/synapse#17086
    • Support for embedded MSC4108 rendezvous session: MSC4108 implementation element-hq/synapse#17056
  • Matrix Authentication Service
    • Support for MSC3861
    • Support for Device Authorization Grant
• Clients
  • SDKs
    • Rust SDK: https://github.com/matrix-org/matrix-rust-sdk/tree/poljar/qr-login
    • Vodozemac: Add an Elliptic Curve Encryption Scheme vodozemac#151
    • Ruma: client-api: Add support for MSC4108 OIDC sign in and E2EE set up via QR code ruma/ruma#1800
  • Element Web
    • Support for MSC3861
    • Support for MSC4108 on an existing device to show a QR to sign in a new device: MSC4108 support OIDC QR code login matrix-react-sdk#12370 and MSC4108 support OIDC QR code login matrix-js-sdk#4134
  • Element X
    • Support for MSC3861
    • Support for MSC4108 to scan a QR to sign in: QR Code Login Flow element-hq/element-x-ios#2767 and Sign in with QR code element-hq/element-x-android#2793

Video demo:

[cyrneko]

finally, it is no longer just an idea presented at FOSDEM 🥳

[ara4n]

tbf there was already MSC3906 - which this will presumably replace, by making it play nice with native OIDC (MSC3861) :)

[dkasak]

I find these terms ("initiate" and "reciprocate") mildly confusing and always have to pause a second to understand which is which. A better pair might be "petition" and "grant"?

Though if these were chosen to align with some prior art elsewhere, it's not that horrible.

[hughns]

I agree that the terms are not ideal. I think I chose them as they are used elsewhere in the Client-Server API specification. I'm not sure "petition" and "grant" are better though!

Another way we could describe it is by defining the disposition of the device.

So, the "initiator" could become the "un-authenticated device". And the "reciprocator" could become the "authenticated device"?

[davidegirardi]

I think a device, the unauthenticated one, "wishes" to login and the other, authenticated, one "grants" it.

[hughns]

I think a device, the unauthenticated one, "wishes" to login and the other, authenticated, one "grants" it.

This "grants" terminology clashes with OIDC.

In OIDC the OIDC Provider "grants" access after the user has "consented".

Specifically, the device doesn't have the authority to grant access. Only the OIDC Provider.

[davidegirardi]

What about `which wishes to login, or an existing device that wishes to open for a login" then?

[Beryesa]

Btw can we get the inverse option too? Logging into the desktop/web client through QR on mobile, similar to Whatsapp Web or Discord log in.

[hughns]

Btw can we get the inverse option too? Logging into the desktop/web client through QR on mobile, similar to Whatsapp Web or Discord log in.

Yes, this proposal allows for this flow too. 👍

[albertotirla]

this MSC allows for logging in and verifying a device with a qr code, but as it's known for some time now, qr codes present significant challenges to visually impaired people, who can't see the portion of the screen the qr code is in to scan it, because most assistive technologies aren't advanced enough for that. So then, what about visually impaired people who also want a quicker login flow?

Here's a proposal I thought of, based on what other apps do about this, like whatsapp for example:

• only the already signed in device can create a code, this removes complexity significantly and allows for more suppositions to just be encoded into the code itself
• the code is preferably numeric only, for eas of entry, and hopefully not longer than 10 digits, assuming that such is possible
• when the person logs in with such a code, it should be decomposed in more or less the same way as the qr code was, except that perhaps some options should be sent over the insecure channel, for the code to not be very long
• none of the payloads and mechanisms presented in this MSC have to change whatsoever, this can still be called qr code login, even if it's technically not really a qr code anymore

There are two more interesting alternatives I thought of, which may or may not be of more use:

• the first device generates a compressed sound signal, containing the string the qr code did, with error correction for ambient noise and whatnot, meanwhile the other device uses its microphone to record it. Afterwards, the signal is validated and potentially fixed using the error correction bands, which may have to then be stripped with an equaliser, then the rest of the communication can continue normally. If you think this is potentially discriminating people who have both a visual and a hearing impairment, my preliminary thoughts on the matter suggest that's not necesarily the case, because the other device records the signal, not the person, and if it errors due to interference, it would have errored anyway, regardless whether the person hears it
• nfc chips could also be used, if they're available on both devices. How this would work is that one would be configured as the transmiter, so to speak, it will contain the contents the qr code should have. Then, when the other nfc enabled device gets really close to the first, it gets sent that binary string, which can then be parsed according to the specification

What do you think, would any of this be possible at all? true, we can login normally, by specifying a homeserver, being redirected to the oidc provider and going through all that stuff, but just because we can't scan the qr code, we shouldn't be barred from this kind of quick login. So then, let's see if we can make matrix more accessible, from the roots rather than relying on the clients to implement something nonstandard, if at all

[jotoho]

Some first thoughts on @albertotirla's proposals, from a random matrix user just watching the PR out of curiosity:

Proposal 1

This proposal might prevent QR code login from being used in the common usecase of wanting to use your logged-in smartphone/tablet to quickly login a device without a camera, such most desktop (and probably some laptop) pcs. A PC at work or school, for example.

An authentication code of format [0-9]{10} would only be ten billion possible combinations. Server side protections against brute-forcing could (partially) migitate risk of an attacker guessing, but my gut feeling is that that might not be enough, if the attacker has access to many IP addresses, such as via a botnet.
Especially since I don't know how large homeservers might grow in the future and an attacker might just have to guess the combination of any user currently trying to login, if they don't care about compromising a specific account.

Edit Addendum: Maybe pass-phrases would be preferable to numeric auth codes? Though if relying on the user manually entering codes, the expiry must be generous enough to not be a major hindrance, even if the user is somehow slowed.

(Also, I really hope any login is exclusively done over secured channels, such as HTTPS.)

Proposal 2

The sound code login idea sounds interesting, but also unsuitable as a default(-ish) login method. It might be promising as an optional alternative to QR code login.

In many scenarios intentionally causing noise is not desirable or socially acceptable.

I suspect the sounds generated might not be pleasant for humans and that many potential client devices do not have any attached microphones (or speakers). Even some smartphones intentionally do not have a built-in microphone, or have microphone access restricted.

Additionally, depending on where you are, unauthorized recording of sound-encoded authentication codes might be easier than being in a position to repliably scan a displayed QR code on a target's device.

Proposal 3

NFC-driven login sounds interesting, but has the restriction of likely being limited to smartphone-to-smartphone login, which cripples it's real-world usefulness.

NFC chips are only common in smartphones, to the best of my knowledge, and I currently do not see any trend to add them to many other potential matrix client devices.

[albertotirla]

ok, so let's address this in order. I'll focus more on your issues with proposal 1, however perhaps it will be nice to modify this spec to have a pretty much plugginable architecture for how the code is generated, because it's the same information anyway

• whatsapp does it with a shorter code, it's fine, I haven't heard of anyone trying to login like that and succeeding. It also works with 2fa and authenticator apps, the procedure is similar, although arguably the user has to enter the password and such before arriving to the second factor login
• the code can be brute forced, but see the rest of this pr. I specifically said none of the other flows are modified here, so the insecure session is done the exact same way, insecure push and pull get wrapped to make secure versions, etc etc all the same
• there's a timeout for the loggin flow, like with the qr code way, but because it's a VI person most likely to use this, either the timeout is per digit which would be difficult to implement, or it should have to be enlarged to like 5 minutes or so, because the user has to both hear the digit from the phone while navigating character by character, and type it on, say, the computer
• like with the previous issues, the brute force attack will still be mitigated only at the last step, where the user is asked to check if the other side is displaying a check mark, which I presume will be read by a screenreader. If not, well, they should either cancel the login or let it expire on its own, no harm done
• qr code login wouldn't be hindered in any way by this, that will continue to work, except that now the client also shows the code below the qr one which should be scanned by the other device, see whatsapp
• when it comes to the code, even if you're logged into the phone, you can still read it char by char and type it on the computer that way. Also, as far as I know, this is possibly a flow encoded in oidc, although not like this, with secure channels and all that, so it should be supported in the future regardless
• look in the mitigations section of this pr, there's something about rate limiting there, people should implement that

The other methods aren't very important, but quickly about the sound one

• the sound wave doesn't have to be audible, or even loud for that matter, see amazon alexa vulnerabilities triggered by commands synthesized under the level of human hearing, and even so they got picked by the microphone just fine
• I haven't heard of a device which doesn't provide means of recording something, be it with a crappy microphone, in a very long time. And yes, microphones are locked down with a good reason, however the matrix client in question has to ask permission for it, it'll have to soon enough anyway, when it comes to calling
• for the someone recording the thing case, see above, rate limiting as well as that other protection about the check mark on the other device and the two digit code they have to type