Inform user if they attempt to login by password when account is associated with Twitter or Facebook

[tfmorris]

If the user attempts to login with a password to an account which is associated with a Twitter or Facebook account, they should be prompted to log in with the relevant associated account. There's no need to tell them the name of the account, just the name of the service.

I don't believe this reduces security at all and it improves usability for people who don't remember how they created their PyBossa account in the first place.

[nigelbabu]

I wasn't sure if I wanted to leak that information :) But, if you think it's a good idea, I'm happy to change the behavior.

[brierjon]

The login prompt with the method that is associated to enhance user login experience to know how to login might outweigh the risk of exposing the user's login preference. Alternatively we could email the user identifying their login method, but this seems excessive and an undue burden which would likely turn away returning users.

Additionally we should look at the general behavior of this prompt in a wider view than asking them to sign in to help in preventing future frustrations or confusion.

Currently the login process is isolated to a single account login option. User accounts should be able to associate multiple account login methods.

Example: Users create account using an email and password with their gmail address. Users return and try to use the Google login instead of the email and password. They cannot log in via Google as an account already has that email or user name is prompted even though these accounts share the same email or username.

Instead of the warning alone the behavior or just prompt to login with the other account it should prompt of the conflict then redirect the user to login with their previous login method. Upon successful login redirect the account holder to the login method which was attempted and ask if they would like to add this login option to their account. Thus allowing us to associate the user with multiple login options. This would also require the ability to remove login options without deleting accounts.

I have not looked at how much work this would be, but this is a better practice that scales with additional logins and is more robust than the current setup.

Additionally this multiple account/login association could be further harnessed for social network feature integration in the future (eg identify friends, etc upon elasticated permissions requests for these features at the time of use (not upon signup as this increases barriers to joining/adding the account and increases information risk unnecessarily)).

[teleyinex]

Hi there,

Good feedback indeed :+1: For me the only problem of this approach could be the following:

What if a user registers someone else e-mail? Then, you cannot or you should not merge their accounts :-) Thus, I think that I like from your proposal could be to tell the user which login method did he used (this is something straight forward to do), so he can try again with it.

Note: Twitter does not expose user e-mail via the API, so when you sign up with a Twitter account if the user does not provide a real e-mail, we will not be able to send back an e-mail. PyBossa detects this case and warns the user until he fills an e-mail, but it could be a faked one (probably we should validate it).

Another item to think about it: I've checked Github account process to see if they allow you to merge sign-in processes. If I'm not mistaken they do not allow you to do so, or at least I've not found it. The same for Twitter. Do you know other services that are allowing multiple-sign in processes for the same account? It would be great to learn a bit more about this idea.

In summary: what do you think about just sending an e-mail with the sign in method that he used as a first solution? Meanwhile we should explore a bit more about how to merge account sign in :-)

[brierjon]

Well to prevent the registration of another's email we should be prompting the user to confirm the email address via a verification link provided to that email address (salted hash generated for one time use for the confirmation). If they cannot confirm ownership, do not allow account to be created. This is common practice to ensure identity and valid email ownership.

The Twitter login example provides an excellent case for the redirect of the user to the preferred login method. Additionally we could request an email to be associated with an account for recovery purposes after creating an account (and one time after implementation of this feature). The confirmation of ownership as stated above could be used for verification. The multiple account attachment (even after logging in for association) will help in both strengthening the user's identity as well as provide alternate recovery options in case one service breaks or disappears or the user does not want to provide an email directly.

Regarding: "merge sign-in processes" the idea is not to merge sign in processes, but to validate multiple accounts to grant access for a user to login. Thus a user account should regardless of sign in method have a unique id generated not associated with a particular login choice. Then each login process would be verified to grant access for that user id.

An example of the multiple sign in you could look at for linking login options you could look at http://www.codecademy.com Users can attach multiple login methods under account settings and use those accounts to login. This can be if the service wants to allow delegated access or be a primary access point as well as balance security. They match on email thus if you create an account with a gmail address and logout then try to login with Google you will be prompted for permissions (if already logged into Google) and automatically matches. Else I would assume the login would create a new account. Thus this could end up with duplicate accounts though this could be remedied by letting users associate accounts in their account settings and if a duplicate is detected and permissions are allowed merge the user accounts. Also a screen asking the user if they already have an account and to login with that prompt the first time could prevent the duplicate account scenario.

The github lack of this could be for many reasons including security (less to maintain and lower vectors for attack if users only can login at one point under their control. Adding additional login methods means users could increase their exposure with each additional login method since any account compromised would grant access to their account. Though these additional login options are the choice of the user thus their added risk truly.) The associations do not all have to have login privileges, but its a trade-off determined by the designers of the system really. Github does not seem to encourage external social network integration in general which could be a design choice. These choices can change user behavior and influence who might want to join the site or not.

Having the login features available and able to be activated or disabled would allow PyBossa to be flexible for the implementor's discretion for their project needs. Though consideration on how we would do cross project authentication - per discussion https://github.com/PyBossa/pybossa/issues/162 would play into how this might operate.

Summary: -validate email ownership -request either a valid email in addition to accounts without emails provided or request that a user adds additional account associations