Hacker News new | past | comments | ask | show | jobs | submit login
Sign in with Matrix (github.com/mishushakov)
158 points by ushakov on Nov 16, 2021 | hide | past | favorite | 78 comments



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.


glad to see you here and agree to all the things said

btw. if you want to build a proper widget like that in the future, i’d be happy to help! (@mishushakov:matrix.org)


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/


Just tried it and never got a code. Is the source available for this?


See https://matrix-login.lyc.fi , comes with source


The implementation is very simple, it just uses the Matrix SDK to create a direct chat and send a message.


this does not authenticate me on the homeserver and does not grant a token

nice concept, but useless for applications


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.


"Sign in with Google" also grants you access token you can use to access Google APIs on behalf of the user

sorry, but your concept doesn't


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.


On a similar note, check out this PoC I found that steals Matrix credentials: https://github.com/mishushakov/signin-with-matrix


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]

[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 will be adding more (secure) methods as soon as the protocol supports this


Until then, is there _any_ safe way to use this? I do not think there is.


use a burner account


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.


it's my project and you can choose to not use it


U2F?


FIDO U2F will not work if you must enter your credentials on the wrong website.


Matrix doesn’t have this


> 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!


If this is attention seeking though, it should probably have large warnings not to actually use it.


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.


Yes, but idea is that you use your Matrix server to authenticate, not an SSO provider


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.


This is interesting, but when I see a form asking me my server, login and password how can I know it is legit?


It says right on that page it's "Secure" /s

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.


I don't disagree, but in my opinion, this problem should be solved on protocol/standard level not by third-party developer like myself


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).


afaik everyone can initiate a Matrix Specification Change by following the described process: https://spec.matrix.org/v1.1/proposals/


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."


We are actually working on fixing the password sending issue, see for instance https://github.com/matrix-org/matrix-doc/pull/3262

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)


> (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.


Matrix does actually support OAuth (in fact, the mozilla.org matrix server can only be logged in to through OAuth)


> Do I get some sort of token from their Matrix homeserver

correct

after you sign in, you will get a token, which you can then use to authenticate against matrix home server


yes, the form sends a POST request to your matrix server

matrix indeed does have it's own login UI, which you can embed in other applications (but it is quirky)


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.


i was considering somewhat similar approach, where if the user accepts a room invite i would authenticate them

but this doesn’t work, because there is only one standard method of authentication, which is by sending username/password


...Why?

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.


this is neat and i have thought of that

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


Why does a federated sign-in solution for a third-party web app need to authenticate to the homeserver or access Matrix APIs on the users 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?


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?



What's wrong with sending login token via Matrix and asking user to copy it into login form (or just sending auth link)?


Handling login-via-Matrix like email or SMS sounds like the right approach.


i'm all for it and considering adding more ways to login

this project is less than a week old at the time, so only password-based method is implemented


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.

https://matrix-org.github.io/synapse/v1.46/openid.html


Based on reading the title I expected it to be this.


yes, this is pretty much a non-starter for nearly all use-cases.


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.


understandable!

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


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?


one big reason there are things like “Sign in with x” is so that the application can do things on user’s behalf


Yes, with controlled permissions the user can clearly decide about. Nothing gives you full access over an account.


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.


I believe this is the same method Facebook offers, although the access token can only be used to do whatever the user authorized when it was created.


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.


Yeah, that's what I was referring to. Facebook calls the token an access token, FWIW.

Are passwords entered in to a Matrix form sent to servers other than the one specified? If so that's crazy.


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.

Why is it so uncommon?


I love this !!

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?


What happens if the origin server goes bye bye? Does that mean I would lose access to whatever it is I signed in with?

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.


With matrix you can run your own server. So you are in control of when the server goes bye bye.

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.


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.



At least there's no phone numbers to put in.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: