Include IP address and password reset link in MFA email

[iansltx]

• @allenhouchins: User requested this because they want to understand if the initial login was attempted by a bad actor. This way they know that someone has access to the username/pwd of their Fleet account and they can block that IP
  • @noahtalerman: In the interim the user could check out the Fleet server's logs. We think Fleet includes this info.
  • @noahtalerman: Eventually Fleet could send along the IP address in the MFA email.

---

[noahtalerman]

Problem

If I'm using local MFA with Fleet (#22078), an attack vector I'm trying to prevent is an attacker logging in with a breached username/password. That attacker is likely going to be coming from an unexpected IP address, which is useful information for potentially blocking the attacker entirely so my inbox doesn't get deluged with magic links.

Created this per @noahtalerman's Slack request to catalog it as future work.

Also, if I'm getting an email when I didn't expect one, that means the attacker has my password, so I want the ability to reset it ASAP.

What have you tried?

On successful and failed logins, the IP address of the attempt is included in the corresponding activity, but first-party MFA creates a third state where someone has entered username and password successfully (so no login failure activity) but hasn't completed auth (so no login success activity). We'll still have logs for login attempts, but those are drastically most limited-access than the activity log.

On the other hand, adding another activity that would wind up with two activities per successful MFA'd login feels like overkill, so it makes sense that #22078 doesn't include any activity feed changes.

Potential solutions

Include the IP address of the login attempt in the magic link email ("Hi XYZ User, we received a login attempt from 10.13.37.1. If it was you, click here to finish logging in. If not, please reset your password.").

"Reset your password" can just be a secondary action here (link-ified text is fine), but due to where the magic link is in the process the user's creds are burned (and thus need to be reset) if someone gets that far. This is in contrast to magic links as the initial auth factor where a user can safely discard a spurious magic link email because all its existence means is someone knows where the login page is and knows what their email address is.

What is the expected workflow as a result of your proposal?

When I have non-SSO'd MFA turned on for my user account, when I log in with my username and password, the magic link email dispatched thereafter includes the IP address in the message body.