[HN Gopher] Sign in with Matrix
___________________________________________________________________
Sign in with Matrix
Author : ushakov
Score : 141 points
Date : 2021-11-16 13:16 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rvz wrote:
| 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.
| jaimehrubiks wrote:
| 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?
| Arathorn wrote:
| 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.
| ushakov wrote:
| 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)
| redsolver wrote:
| 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/
| ushakov wrote:
| this does not authenticate me on the homeserver and does not
| grant a token
|
| nice concept, but useless for applications
| redsolver wrote:
| 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.
| ushakov wrote:
| "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
| remram wrote:
| Just tried it and never got a code. Is the source available
| for this?
| redsolver wrote:
| The implementation is very simple, it just uses the Matrix
| SDK to create a direct chat and send a message.
| [deleted]
| mpnordland wrote:
| 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.
| meibo wrote:
| 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.
| notreallyserio wrote:
| 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.
| mcintyre1994 wrote:
| 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.
| notreallyserio wrote:
| 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.
| mcintyre1994 wrote:
| 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.
| ushakov wrote:
| 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
| LogonType10 wrote:
| 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?
| ushakov wrote:
| one big reason there are things like "Sign in with x" is so
| that the application can do things on user's behalf
| detaro wrote:
| Yes, with controlled permissions the user can clearly
| decide about. Nothing gives you full access over an
| account.
| LogonType10 wrote:
| 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.
| infogulch wrote:
| 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?
| LogonType10 wrote:
| 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.
| ushakov wrote:
| the demo is hosted on GitHub
|
| https://github.com/mishushakov/signin-with-matrix/blob/maste...
| teitoklien wrote:
| 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
| somenewaccount1 wrote:
| 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.
| kevincox wrote:
| 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.
| daleharvey wrote:
| 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
| marcodiego wrote:
| This is interesting, but when I see a form asking me my server,
| login and password how can I know it is legit?
| dane-pgp wrote:
| 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
| zorr wrote:
| Based on reading the title I expected it to be this.
| ushakov wrote:
| 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
| jamietanna wrote:
| 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?
| ushakov wrote:
| There is open-issue here: https://github.com/matrix-
| org/matrix-doc/issues/2615
|
| and custom implementation:
| https://github.com/turt2live/matrix-oauth
| jstanley wrote:
| 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.
| ushakov wrote:
| > 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
| ushakov wrote:
| 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)
| heftig wrote:
| 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."
| driminicus wrote:
| 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)
| detaro wrote:
| > _(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.
| driminicus wrote:
| Matrix does actually support OAuth (in fact, the
| mozilla.org matrix server can only be logged in to
| through OAuth)
| dxld wrote:
| 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 :)
| ushakov wrote:
| 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
| [deleted]
| 3np wrote:
| ...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.
| ushakov wrote:
| 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
| kadoban wrote:
| 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.
| vbezhenar wrote:
| What's wrong with sending login token via Matrix and asking
| user to copy it into login form (or just sending auth link)?
| heftig wrote:
| Handling login-via-Matrix like email or SMS sounds like the
| right approach.
| ushakov wrote:
| 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
| detaro wrote:
| yes, this is pretty much a non-starter for nearly all use-
| cases.
| tialaramex wrote:
| 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.
| ushakov wrote:
| I don't disagree, but in my opinion, this problem should be
| solved on protocol/standard level not by third-party
| developer like myself
| detaro wrote:
| 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).
| kitkat_new wrote:
| afaik everyone can initiate a Matrix Specification Change
| by following the described process:
| https://spec.matrix.org/v1.1/proposals/
| have_faith wrote:
| 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.
| nyx_land wrote:
| 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
| [deleted]
| floatboth wrote:
| 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.
| ushakov wrote:
| Yes, but idea is that you use your Matrix server to
| authenticate, not an SSO provider
| floatboth wrote:
| 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.
| pkulak wrote:
| 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!
| kadoban wrote:
| If this is attention seeking though, it should probably have
| large warnings not to actually use it.
| jeroenhd wrote:
| 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.
| ushakov wrote:
| I will be adding more (secure) methods as soon as the protocol
| supports this
| tata71 wrote:
| U2F?
| ushakov wrote:
| Matrix doesn't have this
| Tepix wrote:
| FIDO U2F will not work if you must enter your credentials
| on the wrong website.
| kadoban wrote:
| Until then, is there _any_ safe way to use this? I do not
| think there is.
| ushakov wrote:
| use a burner account
| kadoban wrote:
| 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.
| ushakov wrote:
| it's my project and you can choose to not use it
| klabb3 wrote:
| > 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.
| oefrha wrote:
| (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
___________________________________________________________________
(page generated 2021-11-16 23:01 UTC)