Security issue associated with melding users based on verified email addresses

[brettle]

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 [email protected]. User does not want to allow LinkedOut to authenticate him to the app. Perhaps user has a weaker password on his LinkedOut account. Perhaps user doesn't trust LinkedOut for some reason. Perhaps user doesn't have a LinkedOut account and doesn't plan to get one. Attacker guesses users weak LinkedOut password or, due to a LinkedOut vulnerability, manages to otherwise break into user's LinkedOut account (or create a new one) with "verified" email address of [email protected]. Attacker signs in to app using that LinkedOut account and, because it has the same verified email address as the user's Giggle account, the attacker's app account is merged/melded with the user's app account, giving the attacker control over the user's app account. When the user signed up with the app using his Giggle account, he did not realize (and had no reason to expect) that his app account security was in any way related to the security of his LinkedOut account. As a result, the app has betrayed the user's trust.

One way (and I'd argue the simplest and most secure way) to prevent the above attack is to require that the user be logged in to both services at the same time before initiating a meld. This is already the case when a logged in user logs in using a different service. So this issue only applies to the case where a logged out user logs in using a service where he has a verified email address that matches the verified email address associated with a different service on an existing account.

FWIW, I don't think setting askBeforeMeld to true will fix this. It looks like doing so will just ask the attacker to confirm that the accounts should be melded.

My suggested fix is to remove this code, and this code. A user would still be able to meld his accounts but he'd need to be logged in to two at a time.

The primary downside to such a change would be that the package would no longer prevent a user from creating multiple accounts with the same email address. If such behavior is desirable, it can be achieved more directly by registering a validateNewUser handler that checks for existing users with the same verified email.