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

[dkasak]

A requirement of this proposal is that the QR code needs to contain 1) a 32-byte Curve25519 public key 2) the URL of the rendezvous server session. This makes the proposal to turn it into a short numeric code a non-starter.

(Also note that the standard way of commenting on MSCs is by using the Files changed view and leaving comments on particular lines, by clicking and dragging on the blue + sign that appears when you hover over a line. However, given the context of accommodating visually impaired people, this may pose challenges, so consider this as just an FYI.)

[albertotirla]

for the first issue, it could be relatively simple to fix

• the binary string is first compressed, with lzma or another high compression ratio algorythm. For reproduceability, perhaps pregenerate a compression index or dictionary for the known parts of the string and store it in the MSC, for clients to directly use that one, so that some space in the compressed byte stream is saved because the header isn't required anymore
• just like we can represent a cryptographic key as a set of emojis, I'm sure we can represent the compressed data stream as a set of numbers. May be longer than 10 digits, but considering the code and the compression algorythm involved, it couldn't be much longer either
• or perhaps the sound based carrier wave is indeed a slightly better idea, with some alterations, as discussed in the previous comment
• maybe the code could be shortened by having the user type their homeserver before logging in, however that might not be better than normal login
• what if we require devices to connect to each other via bluetooth, or find one another via the network, zeroconf discover stile and send the code that way?

Anyone any other ideas though? I'm trying to come up with a scheme for us to also be able to use this kind of login, but surely I might be missing some idea which is better, after all whatsapp used a similar method and it works for them, perhaps we should simplify our flows?

For the second, I thought that might be the case, and github isn't accessible enough to be able to comment on multiple lines, just one at a time. However, when I asked that in a matrix room, I'll leave the name of that room out to not incriminate people who don't want to be incriminated, people told me to do it this way, because I didn't know on what line to put the comment. Either way, I'll know for the future, in case there's an actual line to comment on

[albertotirla]

so, given all the feedback in the previous comments, and also due to a friend of mine who gave me an idea, I think I have a better grasp of what we would need to make this work

• the binary string is generated, as usual, nothing to see here
• the blob goes through a base64 encoder
• it is converted into sound, like I said before. We did establish that just using sound as a carrier wave for raw data could be very unpleasent for the human ear, and upon further discussions with the before mentioned friend, I came to realise that if we do it above the level of human hearing and blast the data that way, we could trip some emergency alert tones and stuff like that, so that's out of the question as well. We should use a nevertheless standardised method for generating those tones, something which doesn't hurt the human ear and something which can't easily be confounded for other kind of traffic over sound waves. In this instance, I recommend morse code, because
  • it's pretty ubiquitous, it's well understood
  • we can use a more specific frequency, so that we can better isolate ambient noise and whatnot, we don't have to push that data over all bands with error correction bands as well, because now the sound has a well-defined shape, like the qr code for that matter
  • it can encode any length of data, as long as the user can wait for long enough for the thing to be played, which is a small concern, but since morse code can be pretty fast, I don't think we should wory
  • it doesn't require simplification of the protocol, because the exact same binary string of the qr code, with some transformations perhaps, can be encoded in morse no problem
• any device can generate it, and likewise any device can scan it, as long as it has at least one microphone, obviously the more microphones, the more likely that the signal is recieved without distortions and other channels from the recording can technically be used as error correction in that case
• once the binary string gets on the other side, the mechanisms are executing as planned in the rest of this spec, this problem is essentially ways in which to get that binary string from one device to another, one solution to that being a qr code, the other is this
• after successful login, because this is recording sound, perhaps have the code that has to be typed be three digits long instead of two, to mitigate some of the issues above

If this is to be deemed acceptable for most people here, I recommend we make it so that we can't find ourselves in the situation where one client only implements morse code, another only qr and then it's users who suffer. So, I think clients who implement the qr flow should be required by the spec to also implement the morse code for accessibility reasons, but those who implement only morse code don't have to also implement qr code, because anyone can still use the morse code login flow even if they can see to scan a qr code.

Is this a better idea? perhaps it's time we try something out and see if it could work, are there issues I overlooked? or maybe, who knows, is it worse than those which came before it?

[jotoho]

@albertotirla

The spec isn't law. Even if the spec said implementations supporting QR code also need to support audio code login, I think neither the spec nor servers reasonably can (or should) enforce that rule.

And if I understand correctly, one of the goals of moving auth away into MAS and using OIDC is to make implementing compliant clients easier.
Adding a hard requirement to support a login method that at least some maintainers might not be interested in developing/maintaining, seems counterproductive to that goal.

So if the audio login method is going to, at most, be an (optional) alternative to QR code login anyways, I feel like discussions on that probably shouldn't derail discussion/progress on this QR code login MSC.
If there's any interest from implementation maintainers, it might be better for you to propose a seperate MSC for that. If implementations aren't interested, it's dead in the water anyways.

I've said my two cents, so I'll stay out of the discussion from here on. 🙂

[albertotirla]

yeah, people told me throughout today to make a new MSC for this, which is what I will do soon enough, not sure on specific details unfortunately. So yeah, for the other people beside me who want quick login to be accessible to everyone, and especially if you think the morse code idea has some merit to it, stay tuned!