Sign in with Matrix
github.com
github.com
The direction we're headed in the Matrix spec core team is instead towards replacing Matrix's current auth mechanisms with normal Open ID Connect (rather than wrapping our own OIDC-like thing, as we do today) - as per https://github.com/sandhose/matrix-doc/blob/msc/sandhose/oau.... The common login flow would then be for users to be authed by their server using a trusted OIDC identity provider, rather than ever trusting arbitrary clients with their credentials.
This is not finalised yet, as we still want to find ways to support folks authing on known trusted clients without having to embed a web browser - and we don't want to design out cryptographic login (e.g. OPAQUE style auth mechanisms) in future.
btw. if you want to build a proper widget like that in the future, i’d be happy to help! (@mishushakov:matrix.org)
nice concept, but useless for applications
sorry, but your concept doesn't
You shouldn't enter your username and password for one website into another. You shouldn't train users to do so either. Using this reinforces the problematic security behaviour every company had been trying to unteach users for ages.
I think the concept is great, but there should be an OAuth callback running on the homeserver, where the user perhaos enter their password, rather than a login form embedded into the website itself. This shouldn't be impossible to accomplish with a little companion tool you can run on your homeserver to receive and deal with callbacks. There'd be no need for the server admins to choose which applications to integrate to or not, just plonk it behind a proxy and you're done. That way, the mapping between URL and credentials remains and the impact on server administrator workload should be minimal. Of course, there's still a need for a good security strategy to make sure the OAuth UI doesn't get hijacked, but the concept is a lot more workable than this example.
If the only way a project can be used safely is with a burner account, should this actually be released? It does not appear to have any warnings on it either.
> You shouldn't enter your username and password for one website into another.
A stronger version of this is you shouldn't embed any kind of authentication/authorization widget of one website into another, even if the widget is supposedly under complete control of the auth provider (i.e. an iframe). For instance, is an embedded SSO widget without password entry okay? No. Cue Google YOLO clickjacking.[1][2]
There's a reason OAuth forbids iframe embedding and even recommends JS frame-busting on browsers that don't support X-Frame-Options.[3]
[1] https://blog.innerht.ml/google-yolo/
[2] https://news.ycombinator.com/item?id=17044518
[3] https://datatracker.ietf.org/doc/html/rfc6749#section-10.13
I'd even argue that this is the much bigger point. The only practical way we have to avoid phishing (and its cousins) with password-only auth is teaching users to look at the domain-part of the URL. It's the only thing I can currently teach my non-technical friends & family.
Human assumptions are basically software that takes years or decades to upgrade, among other problems. Can't really stress enough how important it is to foster and teach best practices in this space. It's a giant shitshow to reverse these things.
Fortunately, Matrix is still nothing my grandmother would use, but it would really suck for Matrix if they have yet-another hurdle to overcome in reaching the mainstream. If I were Matrix, I'd be extremely concerned with this.
If a protocol didn't support something I wanted to do, I would simply not do it rather than implement it in a way that is wrong and also dangerous. If a protocol couldn't support something I wanted to do with it or the devs refused to add it, I'd simply use a different and likely better protocol (like XMPP) (also let's be real, the Matrix spec is already huge and has an even bigger, ever growing number of requested additions; I'm sure something like this has been sitting on their back burner for years). But actively making an insecure implementation of this, essentially doing the work of unintentionally making a phishing app and also normalizing it, making it more likely that people would unwittingly use a hostile actor's hosted version, is just weird to me.
Ironically this does also serve as a proof of concept for how easy it is to pwn Matrix users
the problem is, Matrix has it's own login system, that does not support OAuth or offer any trust-less methods, such as login requests via a bot (how it's done in Telegram)
currently this is how all clients implement login to Matrix, be it Cactus comments or the beautiful Cinny client
Since the form asks for your homeserver, it seems like I'd be typing my password into a form controlled by you, which seems like a bad thing to train people to do?
EDIT: Also, "requires no backend to function" - but if I want to use this to give users access to their data in my backend, how can I do that securely? Do I get some sort of token from their Matrix homeserver that my backend can use to ensure that the client is authenticated as the user they claim to be? Or do I need to pass the username and password to my backend so that my backend can authenticate them with their homeserver?
Don't get me wrong: I love the idea and it's a cool project & great proof-of-concept. I think the current implementation is not secure enough for me to trust. It's possible that I'm mistaken and it actually is secure! But in that case I'd want to see some substantiated argument in the README, explaining how it works & why it's trustworthy.
matrix indeed does have it's own login UI, which you can embed in other applications (but it is quirky)
However, if the homeserver is using OIDC, the user credentials are handled entirely by the external OIDC provider and the client doesn't get them. But then you should be using OIDC directly and not "Sign in with Matrix."
Of course, untrusted clients can do all kinds of evil things after having authenticated. (And also clients still need the plaintext password at least client-side no matter what we do)
Are matrix devs seriously not aware of what OAuth is and does? That is ... concerning.
correct
after you sign in, you will get a token, which you can then use to authenticate against matrix home server
but this doesn’t work, because there is only one standard method of authentication, which is by sending username/password
A matrix bot could send the user a short-lived token they can paste to the site to authenticate. Optional QR for mobile.
No need for homeserver changes, changing protocols or touching any user credentials.
Since you’d rely on an existing matrix session, the bot could send the token e2ee, meaning after TOFU you could even protect against malicious homeserver operators.
You could also do the inverse, having the user send the token to the bot.
but it does not authenticate you against the homeserver and does not grant you the access token, meaning the application would not be able to access Matrix APIs on user's behalf
That’s exactly what you want to avoid.
The bot can still get things shared by the user like username, avatar, 3pids and pubkeys.
Can you give me a use-case that my proposed solution is insufficient for due to inability to impersonate the user to the Matrix homeserver?
Then I guess I'd have the backend send the user a link with an auth token after joining, that way at least no pasting needs to happen.
this project is less than a week old at the time, so only password-based method is implemented
and custom implementation: https://github.com/turt2live/matrix-oauth
But seriously, no, obviously if you were to foolishly type your credentials for service A into a web form on web site B, now B has your credentials for A. Doesn't matter if that's a username and password, SMS code, TOTP. The only case where you aren't in serious trouble is WebAuthn (and its predecessor U2F) and that's because WebAuthn is bound to the actual DNS name of the relying party to defeat exactly this attack.
From what I can see, it makes a call and receives an access token. This token can then be used to make requests to the matrix server like sending or retrieving messages. If this component is used for a matrix client, this makes sense. If the component is used for another service or app, I don't think this is a good idea.
Something like this really needs spec support, to have home servers act as an auth provider + points to the UI to be used and pass out temporary/limited tokens. You just couldn't trust it otherwise.
Are passwords entered in to a Matrix form sent to servers other than the one specified? If so that's crazy.
however, Matrix protocol does not support auth scopes, therefor it's not possible to control what can or what cannot be accessed with the token, although it's possible to revoke each token
your encrypted chats still can't be accessed
When I do manage to login I get asked to verify my login and when I click to verify just to get rid of the popup it asks me to verify with a security code which if I remember right was one of those "here is 100 character string for you to write down and store in your vault" type situations.
Slack doesnt fare much better, every few weeks when the token expires I have to play "whats the domain for this slack that I literally only need to login and is permanently hidden otherwise"
I dont enjoy being sentimental and "get off my grass", but its seems sad how less impressive but more complicated tech these days
Proxy auth is so easy to implement from the app side, just accept an http header as the user's identity. That's it. I guess there are a couple places you need to coordinate with the auth proxy: which header contains the identity, which path to redirect to trigger an authentication prompt, maybe how to get a listing of other users if the app needs that, etc. But for a first pass this authentication method is by far the easiest to implement from the application's side.
Why is it so uncommon?
I get a lot of people are concerned about the sign-in option presented right now, But the author has already explained , he’ll add a more secure implementation soon, if this gains traction.
I would love to be able to authenticate on websites using my matrix homeserver. Props to the author for such a stellar idea. I’m really excited about this :D
Yes, Google has the same vuln - and Apple - and Microsoft....i feel like they have a bit more stability than any individual matrix server though.
Of course yes, if you are using "someone else's" server then you are the the liability of that provider, just like any other centralized provider.
https://github.com/mishushakov/signin-with-matrix/blob/maste...
Regardless, the lost and banned as well as the privacy crowd are cheering for alternatives like Matrix and this feature is an excellent addition for decentralised chat groups and communication.
I can easily see integration with external and optional third-party blockchain domain solutions (like ENS) for verification without Matrix themselves introducing their own cryptocurrency project or what not.
Job done.