Hacker News Reader

Comment by mpnordland | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com