-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Force users to login to both services before merging #3
Comments
First by way of background for others, here is my security concern. Consider the following attack scenario: The app supports login with either the Giggle service or the LinkedOut service. User has a Giggle account and logs into the app using his Giggle account which provides his verified email addreess of Note that this is not about which providers the package should trust or which providers the app developer trusts. It is about which providers the user trusts. A provider may be perfectly secure, but the user might still not trust it to authenticate him to the app because he knows that the password (or other means) he uses to authenticate with the provider is weak. Also note that fixing this would not preclude the app developer from providing a means for an administrator to merge accounts that the admin has determined (hopefully via some secure means) actually belong to the same person. The issue with the current implementation is that it provides a way for an attacker to initiate such a merge. |
Where do we draw the line between security and convenience? Having perfect security isn't always easy when you wanna make your site usable to the masses? |
As I'm sure you know, one major rule of usability is the "rule of least surprise". In the security context, being vulnerable to some attacks is more surprising than others. For example, when I sign up for an app using my email address and a password, I am not at all surprised that an attacker who can access my email account (or intercept messages to it) can reset my password and access my app account. I'm also not surprised that an attacker who gains access to the app's database can access my hashed password. In fact, those are two reasons that I might prefer to login with an OAuth service where I have a strong password (and/or additional security precautions). However, if I used such a service to sign up for an app, I would be quite surprised if someone else logged in to my app account using an account I have on a different service. Of course, what is surprising in one context might not be surprising in another. But since this is a package, we know very little about the context of the app which is using, and it is better to err on the side of more security even if that means less convenience. It's also worth pointing out that logging in is usually a relatively rare event in terms of the user's overall interactions with an app. So the convenience sacrificed in the name of security is arguably less important here than in most other places. That said, I don't think this needs to be a particularly big inconvenience. If the UI distinguishes between signing up and signing in, I think a user will be much less likely to accidentally create multiple accounts using different services. He will probably remember that he already has an account, but might not be sure which service he used. When he tries to sign in with the wrong service, it fails (instead of creating a new account) and he tries again with a different service. And if he wants to be able to login with multiple services, IMO it's not particularly inconvenient to login with one service and then add others while logged in. Lastly, if the app developer wants to completely ban multiple accounts with the same email address (with the knowledge that doing so necessarily allows an attacker to determine which email addresses already have accounts), he can register a validateNewUser handler that checks for that. Hope all that makes sense. |
It makes sense, but the big problem here is that this would need changes to core packages functionality, as We could of course override that behaviour with this package and the useraccounts system, but then that needs to be VERY clear as we're altering default behaviour of the framework provided account services. Another option would be to make our own forks of the oauth flow and have that behaviour be different and more secure than the core packages. |
We could throw a |
If you're logged in with an account and you login with a provider, then one-account will add that service to the currently logged in account if and only if there isn't another account connected to this service account. If that service was added, then we just let the login go though, to get the lastest data from the service account, it won't create a new account. |
I think I got confused as to what we are talking about. I'm now realizing that when you said "this would need changes to core packages", the "this" you were referring to was probably my suggestion that "the UI distinguishes between signing up and signing in". Is that right? If not, please clarify. Thanks! |
It's the register vs login thing I was referring to. Today with Today you can change accounts when you're already logged in by logging in to another account. I think we can change this behaviour with our package but we need to be very clear in our documentation that this is different from the usual behaviour of the accounts system in meteor. I think that I think that I think that we should have |
Thanks for clarifying and sorry for the earlier confusion. I agree that we need to be very clear in the documentation about how we are changing behavior. That said, I don't think what we're talking about is necessarily more radical than what a lot existing accounts-related packages do and I think if we do it right it will actually make the accounts system behavior more consistent and easier to understand. For example, right now, Here's my prefs for how it should work:
That leaves the "add service to existing user" functionality. I don't see any harm in adding this to |
I agree we'd need specular API for password and oauth:
should be the only two methods to log-in users or create new ones and, at this point, With this two separated paths, it should be esy enough to put in place a clear logic for accounts melding/merging/linking |
...to keep backward compatibility we could suggest to add a configuration parameter to the |
Security concerns, brought up by @brettle.
Where do we draw the line on trusting the providers?
This will give the user the control of trust instead of the app developer.
The text was updated successfully, but these errors were encountered: