Hacker News Reader

Comment by portaouflop | Hacker News Reader

If you (the service you are signing up to) use a good auth solution it will prevent that and give you the option to merge the 2 identities (matching on the email address)

sadly most don’t care about how bad their authN is which is mind boggling to me but reality

View on HN

Is that the right behaviour?

Imagine the following scenario:

An evildoer hacks into my e-mail account, michaelt@example.com, creates a salesforce.com account (with a password). They delete all the e-mails about account creation.

I discover the hack and change the passwords on every account I know about - but I don't know about the salesforce account (in fact I don't have the password to it) so the hacker retains access.

Should the hacker be able to visit gitlab.com, hit the log-in-with-salesforce button, and get access to the michaelt@example.com account?

You have to verify access to the email with a code to do the merge. That solves your issue

But what if the attacker deleted the verification email after they merged the GitLab accounts? Then they still have a backdoor to your GitLab.

As far as I can see you are assuming an attacker with permanent access to your main email account.

If someone has persistent to your main email account you will have all kinds of problems.

As somebody else said, once your email is compromised you are fucked and have far larger problems than a single individual site.

I agree sibling comments are not quite correct about persistent email access. You could fix the email problem while the "backdoor" to Gitlab remains.

The problem statement says this about corrective action:

>I discover the hack and change the passwords on every account I know about

In actuality, the corrective action is to change the passwords and revoke any SSO integrations.

To the original point, this does add more overhead to the process, probably isn't obvious to most people, and depends on the site having clear UI for the topic.

If the attacker has hacked your email then they could presumably do a reset flow on gitlab and reset the password and clear any evidence. The identity provider step is unnecessary. If we assume that linking the salesforce account to gitlab generates an email. Then unless the attacker has persistent access to the email account you’d know about it. If they have persistent access then the existence of the linked account doesn’t matter. They can just do password resets whenever. This does assume linking an account generates an email. MFA or forced authentication with existing account to link a new identity provider makes sense. But in terms of password reset a hacked email is pretty much the keys to the kingdom anyway.

I suppose the slight difference is that with the password reset flow you’d know that you couldn’t login. But nine times out of ten I’d imagine you’d just do your own password reset upon finding you couldn’t login.

No. No. God no. Do not ever do that.

The email address you get from an oauth provider should never be trusted.

Mostly but not entirely true. If Google oauth gives you an @gmail.com email, you can trust it.

A more accurate formulation would be: the email address you get from an oauth provide must not be trusted unless the oauth provider controls the email domain and guarantees no re-use of addresses.

Not that it’s practical to special case every such provider, but with Gmail handling 25% of email, there can be good UX affordances for them a few others.

Even in the case of gmail, which is the best case, you can not be sure the person in control of the Google account is the same as the one that used that gmail address to create an account on your site. The person might have got their Google account hacked, they might have used a shared gmail account to sign up, your service might not have been properly verifying email addresses when they signed up, etc.

But yes, to be fair, if you have email-based password reset functionality, it is not really an additional security vulnerability.

Control of the Gmail account and ability to get an oath token for that account are one at the same, as far as I know. Both indicate you’ve authenticated as that user with Google.

There are a few others. I’m not sure it’s worth the special casing, but it can be a better user experience.

'Never' is a bit strong. It depends a lot on what you're using the email address for. And it's probably safe to trust gmail addresses coming from google, for instance.

Reply on news.ycombinator.com