Allow users to disable unknown sign-in notification

added devopsmanage featureaddition groupauthentication and authorization [DEPRECATED] security typefeature labels

@rchan-gitlab I appreciate your thoughts on this feature proposal.

Hey @dblessing thanks for the ping.

This issue reminds me that one time I accidentally log in to one of the GitLab bots using my phone (with 1Password), and quickly our SIRT was able to catch that and reacted accordingly.

I think even with 2FA enabled, there are still cases where instance admin would want to receive a notification when Unknown sign-in happens.

I'm more inclined to stay the way it is, with the flexibility to users that they can choose to disable that in their profile (your second suggestion). Also, instance admin has the option to disable this feature for user. Something like "Allow end user to disable unknown sign-in notifications when their 2FA is enabled."

I hope in that way everyone is happy, while not compromising the overall security of our users.

@rchan-gitlab

I think even with 2FA enabled, there are still cases where instance admin would want to receive a notification when Unknown sign-in happens.

This feature does not notify admins of sign-ins - only the user that the sign-in is for.

Does that change your opinion any?

@dblessing Oh apologize for the inaccurate wording, I meant there are still cases where instance admin would want their users to receive a notification when Unknown sign-in happens.

I still have the same opinion about this, let me ask about appsec team to see how they think of this matter.

cc @gitlab-com/gl-security/appsec

Sounds good to me. I was hoping to avoid yet another configuration, but I definitely see value in this option for cases like GitLab.com.

cc/ @mushakov from a product perspective.

@dblessing

We had a brief discussion about this feature request at https://gitlab.slack.com/archives/CNZPN8BT3/p1600035388449400?thread_ts=1600035307.449200&cid=CNZPN8BT3, it is mainly about the concern when a user is compromised then there's no instant way of notifying the user since the only instant channel to reach to the customer is disabled.

@dblessing @rchan-gitlab Are we still hearing from a lot of customers about this email being sent too often? I'll set this feature to %Awaiting further demand to see if we get more user interest. I agree with giving more flexibility but tying this to 2fa seems a bit off to me. Yes, the account is more secure but it can still be compromised.

@mushakov No, I don't think we're hearing a ton of concern.

Let's change the issue title and description to reflect the security team recommendation to make this configurable.

@dblessing Hi Drew, a question based on the proposal - who can turn off unknown sign in emails, provided the application setting is active - is it "any user" in the instance or is it "any user who has 2FA active" ?

Like you mentioned, a user without 2FA is a more vulnerable than a user with 2FA, so I wonder if not allowing users without 2FA to turn this off at all would be ideal. (As much as I hate spamming, maybe this would nudge them into following the best practise of setting up 2FA for their account because of too many notifications?)

@manojmj I don't have a strong opinion about it. In general I'm in favor of incentivizing strong account security. The one hesitation I have is with enterprises where they use external auth with 2FA outside of GitLab. But in these cases it may be more appropriate for the instance admin to disable it? What about on GitLab.com with SSO?

What happens if a user disables notifications and then disables 2FA? Do we implicitly re-enable notifications until/unless they re-enable 2FA?

We could always make a first iteration with it more restrictive (only able to disable if 2FA is enabled) and do a second iteration if there's demand.

@rchan-gitlab Thoughts?

I feel more comfortable if the unknown sign-in notifications are disabled for SSO enabled users (Instance SSO not Group SSO), since we have delegated the authentication to the external identity provider. If someone has signed in from an unknown location then it is the identity provider's responsibility to notify users instead of GitLab's.

ping @dblessing for visibility

@rchan-gitlab just to make sure we are on the same page:

I feel more comfortable if the unknown sign-in notifications are disabled for SSO enabled users (Instance SSO not Group SSO), since we have delegated the authentication to the external identity provider

If I am not wrong, we already have these emails going out for all Omniauth provided logins that are unknown - do you mean to say that this "Unknown sign-in emails" feature should go away entirely for Omniauth logins? Or do you mean to say it should not send out emails for Omniauth logins in specific cases?

@dblessing I like the idea of starting with a more restrictive iterations and easing it later if required. Does this look ok to you for a first iteration?

Admin setting:

User setting: (under /profile/notifications)

What happens if a user disables notifications and then disables 2FA? Do we implicitly re-enable notifications until/unless they re-enable 2FA?

Yes, I was planning on doing this. The absolute value of the user setting is taken into account only if 2FA is enabled at the time of the check being made. Even if db value is disabled, we would send out the email if 2FA isn't active for them at the time - that would be the right thing to do.

Hi @manojmj,

If I am not wrong, we already have these emails going out for all Omniauth provided logins that are unknown - do you mean to say that this "Unknown sign-in emails" feature should go away entirely for Omniauth logins?

No, I mean for this kind of logins, we can let admin to have the flexibility to configure the notifications for their users, as suggested in your screenshots above. For regular logins, appsec's general suggestion is that we do not give up this important feature (unknown location sign-in notifications) unless it is asked by a majority of users.

Or do you mean to say it should not send out emails for Omniauth logins in specific cases?

Yes, as I mentioned above, make it configurable only for Omniauth logins, but not regular email/pw combo login. Since disabling that for a username/pw combo user, they will have no way to tell their account is compromised through third channel, in this case, email notifications.

@rchan-gitlab Excellent, I think I got you

Is this what you have in mind for the first iteration?

There'd be no "user" specific setting (like my screenshot above) and there'd also be no consideration about the 2FA of the user. Plain and simple - allow admins to turn off notifications for unknown sign ins - if user is logging in via an Omniauth provider. Does not matter if the logging in user has GitLab 2FA enabled or not.

Is my understanding correct?

I think we're getting too far away from the initial issue and the problem we're trying to solve.

The original problem from users, from the description is:

some users still receive the notification when it's not particularly helpful to them. For example, in a case where the user's IP address changes frequently and they also have their browser clear cookies on exit. This will cause the user to receive a notification on each sign-in assuming the browser has been closed. We should make the user experience with this feature as good as possible. No one likes spam/unnecessary emails, but we also need to balance security.

If the user's IP address changes frequently and they don't accept cookies like the one we use to track known sign-ins, then the new sign-in notifications are useless. A user isn't going to pay attention or notice if a notification comes in for a sign-in that wasn't them. They're already conditioned to ignore them.

I'm not opposed to changing the strategy for OmniAuth sign-ins (and we should improve the messaging in these cases anyway) but that still misses the original target user that spawned this issue.

In trying to think of a compromise, I come back to 2FA. I think the risk of account compromise with 2FA is really, really low. We don't use SMS so what's the attack vector? You have to obtain the user's phone or Yubikey.

I agree with @dblessing.

Hey @manojmj, appreciate the PoC screenshot, it's really intuitive. To clarify, my views are below.

For regular login, admin should not have the ability to disable unknown-sign in notifications, with or without 2FA
For omni-auth login, admin could have the ability to disable unknown-sign in notifications, since we are delegating the authentication to omni-auth provider.

Hey @dblessing thanks for the discussion.

Enabling 2FA could lower the risk, but it is still "hackable", such as
- Password manager account compromise
- Stolen phone/laptop
- Leaked recovery code
- Proxied phishing sites

Personally, I would prefer receiving a notification email every time I sign in from a new location than not receiving one. It gives the service provider more credibility in terms of security. That I can rely on its security defense.

cc @gitlab-com/gl-security/appsec to bring in new perspective.

@rchan-gitlab I can understand the user, but at the same time I would like to know if someone other than me connect on gitlab. It may not never happen, but if it happen once then it would justify receiving those emails time to time.

My experience with that is relatively good: I only receive limited emails, but maybe it's because I'm not really moving.

This is what I did received recently after moving:

Maybe increasing the user fingerprint (like OS details, screen resolution, location, etc) and trying to adapt the rules may be a good balance?

Personally I would prefer to receive a notification every time there is a new sign in that differs from usual.

What would happen with a customer if they disable that and something happen? Behind the fact that disabling this feature, I think there are probably some legal aspects to also take into consideration maybe?

some users still receive the notification when it's not particularly helpful to them. For example, in a case where the user's IP address changes frequently and they also have their browser clear cookies on exit.

This happens in my case, (my browser is set to clear history on exit) I usually get one mail every day and now I'm wired to ignore them, and this might cost me someday. I think it will be great if it's possible to reduce the false positives rather than brining in an option to turn off the notifications.

Personally I prefer to get notifications about suspicious logins but not when my browser cookies are cleared or when IP gets changed.

@rchan-gitlab

For regular login, admin should not have the ability to disable unknown-sign in notifications, with or without 2FA

Admins can already globally disable this feature via https://docs.gitlab.com/ee/user/admin_area/settings/sign_in_restrictions.html#email-notification-for-unknown-sign-ins. And I think that's perfectly fine - this notification might not be useful to self-managed instances that are otherwise tightly controlled.

Since self-managed admins can disable the feature if it doesn't suit their use-case, I agree with @vdesousa that it may be better for us to spend time improving detection rules. This would improve the situation for GitLab.com and would ideally continue to reduce the reasons a user would need to disable the feature. Of course, improving the feature itself will also benefit self-managed users. We already have an issue for improving detection: #215931

Thanks team for the additional comments, really appreciate the insights here.

added sectiondev label

I totally agree that accounts managed by an admin should be configured more globally.

In my case this is a private GitLab account with 2FA enabled and I get this email every day I log in. So having an option in my settings to disable this notification possible only if 2FA is enabled would be very nice.

As one can see the mail makes the impression that I'm able to change the notification...

mentioned in issue #249039 (closed)

changed milestone to %Awaiting further demand

added [deprecated] Accepting merge requests label

changed title from Disable Unknown sign-in notification for users with 2FA enabled to Allow users to disable unknown sign-in notification

changed the description

We also would really like to disable this feature. Using on-prem Gitlab with LDAP auth. Our users are using VDI sessions so they get a new IP every day, and thus an email every day. FYI: We are a paying customer.

@giix You are able to disable the notifications for the instance if you wish https://docs.gitlab.com/ee/user/admin_area/settings/sign_in_restrictions.html#email-notification-for-unknown-sign-ins . Let me know if that meets your needs! This issue is to allow individual users to opt out.

I get this email every single time I login because my IP changes every day. While I understand the initial security concern, the inconvenience outweighs it by a wide margin. It seems pretty obvious to me that it should be the default behavior with an option to disable it. This is close to looking like spam otherwise as there's no option to unsubscribe from it as the laws require.

I have to agree. Getting an e-mail every time I log in from the same computer is rather annoying.

Hello, Any news on this ? Thanks

Any update? This anti-feature is irritating and adds too much friction when logging in.

added security-backlognot-reviewed label

added devopsgovern sectionsec labels and removed devopsmanage sectiondev labels

added security-backlogreview-started label and removed security-backlognot-reviewed label

added groupauthentication label and removed groupauthentication and authorization [DEPRECATED] label

removed [deprecated] Accepting merge requests label

Allow users to disable unknown sign-in notification

Original Description

Designs

Child items ...

Activity