Speaking as project lead for Matrix, while we're always happy to see new projects building on Matrix, we share the concern that users shouldn't be encouraged to enter their Matrix username & password into arbitrary webapps which may or may not be trusted. To be clear: Sign in with Matrix is an independent project from a community member which isn't associated or endorsed by the Matrix core team.
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.
Maybe you are interested in this little PoC I made a while ago which instead sends a one-time-auth code using Matrix: https://loginwithmatrix.tiktalk.space/
It does prove that you own the specific matrix id you are logging in with to the website. It can for example be used as an alternative everywhere where "Sign in with Google" is used, so I don't understand why it should be useless for applications.
Aren't you supposed to use "Sign in with Google" or which ever service to prove to the app that you own your unique id (e.g. email)? If you want Google APIs, then that's a completely different scope here.
I love the idea of using Matrix as a federated login system. This implementation however, is not acceptable.
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.
(Disclaimer: not a security expert, opinions could be wrong.)
> 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]
As software engineers, we really need to consider not just if we can do a project, but also if we _should_.
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. You shouldn't train users to do so either.
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.
With everyone here pointing out that this is a really bad security practice, I don't understand why the response from the dev has been "not my problem, take it up with the Matrix spec people".
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
This is probably how you get the attention of the "Matrix spec people". I too would love to see Matrix as an OAuth2 provider, and if this helps that happen, my thanks to the author!
I think the dev might be wrong — Matrix absolutely supports SSO, in fact the server I use (Mozilla's) DOES NOT support password login AT ALL, I can only log in through OAuth.
I mean, this idea should essentially be a proxy to your Matrix server's SSO. This thing would be a Matrix client that uses Matrix's SSO support to authenticate in Matrix.
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.
Doing this for random web apps is bad enough that you shouldn't do it, period. At the very least your README should be covered in warnings that it's a bad idea. Really the only scenario where it is sort-of maybe acceptable if is a homeserver hosts additional software for its users (and then it shouldn't allow any other homeserver to be entered).
this is a valid concern and we have discussed this with Matrix community members and developers
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
So in this system is your software handling the username/password, or is the form provided by the Matrix server?
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.
The website does get your credentials. To be fair, this is how password login with any of the web clients works as well. Which makes it hazardous to use clients not hosted by the homeserver or a trusted third party.
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)
Crazy idea: what if you use a random room ID as an OTP and recognize the user as signed-in as soon as they join that room via an invite or matrix.to link? I'm not sure if this fits within your constraints since it would need a backend but I think it'd be pretty neat :)
That sounds like it would be dangerously MITM-able. Then any invite or link in matrix is equivalent to "let me log in as you" on some other random service.
Ah you're right that would be pretty dangerous. I was hoping it'd be possible to avoid sending an OTP token the user has to paste but I suppose that's necessary to bind the two contexts together.
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.
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
Thanks for the info! Do you know if anyone's investigated OAuth2 or in particular IndieAuth (https://indieauth.spec.indieweb.org) which is an Open Web extension to OAuth2 which would remove the need for client registration, and still allow OAuth2 interactions to remove need for the credentials being shared?
The same goal could probably be achieved by extending Matrix servers to become OpenID Connect providers, but I don't know how easy that is. Apparently the Matrix server implementation Synapse does allow users to authenticate with accounts on an external OpenID Connect provider, though.
I really like the concept, but I'm not happy with the implementation.
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.
Yeah, there's no scopes. Kind of a bad idea, imo, even if you wouldn't be able to read previously encrypted messages.
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.
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
So you're not verifying identity with matrix, you're taking wholesale access to people's accounts? If I wanted to host a phishing page would I need to modify your code at all?
This is like disabling MFA and giving you my google username and password. Actually it's worse than that because Google would probably ask me for an email verification code. Try adding this to a phishing/social engineering framework, they will be impressed.
It's not, log in with Facebook takes you to a facebook.com URL to enter your details. It tells you which website you're logging into. If you have multi-factor auth etc. on your Facebook account then it'll be applied there. Your password never goes to any website that isn't facebook.com and nobody else ever sees it in any form. The login token returned from Facebook to the website can be time limited (in addition to the limited scopes as you highlighted). Facebook should have a UI that allows you to view and revoke any sites you've authorised in this way. OAuth solves all of these problems, but it requires the provider (Facebook or Matrix) to implement it on their side.
Well the form is embedded on your website, not one controlled by the Matrix server. I assume this open source code sends the request directly to the Matrix server. But it'd be impossible for a user to know where it's being sent when they enter their details on the random website that's embedding this. You could watch network requests but obviously when you notice it going somewhere else it's too late and your account is stolen.
Does matrix have anything on their roadmap for signing in without user/password in 3rd party apps? maybe the homeserver can act as an oauth provider somehow.
I have never not been confused when logging into matrix, I signed up clicking a link at work, now if I want to use an app it asks for some server name that has nothing to do with the sever I signed up on (chat.mozilla.org vs mozilla.modular.im vs vector.im?)
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
I don't know why proxy authentication is not more common in open source applications. It's always either built-in authentication or LDAP (which is sometimes only available behind a 'premium' paid version), but both of those still involve the user typing their SSO credentials into the app which handles it as plain text.
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.
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
If you think someone you know is being scammed or targeted by cheaters , do not make them feel embarrassed anyone can be a victim, few months ago I and my wife were scammed about $70,000, almost gave up in life, we were hopeless until a Brother introduced me to April Hoskey from swift Access, a reliable source to recover my funds back and also trade to earn high profit,
contact them via swiftaccess37 at GMAIL dort com
What happens if I am a member of (or host my own) matrix server, and I use it to create an account in one web page; and then later on, that matrix server is deleted forever. Is there any way I can recover my account? This is why I think I prefer crypto single-sign-on (i.e. ethereum projects that allow this). Because I will always be in possesion of my private key. Is there any equivalent to transfer my account across matrix servers?
Is this an out of date April Fool's joke? It's just phishing! Click link to third party website, enter matrix creds directly into website, website gets access to your account and can read and send messages.
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.
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.