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.

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.

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.

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